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ABSTRACT 



This thesis examines the design and development of a desktop prototype of a 

computer wargame. The prototype specifically deals with the ability to format the 

Joint Theater-Level Simulation's Model Interface Program (MIP) into the visual 

interface format of computer graphics known as window management. In this case. 

the Apple Macintosh microcomputer, a desktop computer, was used as the operating 

system for implementation of this prototype. The development of the prototype is 

examined with respect to the current version of the MIP. The prototype development 

is based on software design applications which include design models, correlation of 

programming languages to operating systems, and a breakdown of the design into a 

♦ * 

modular format. The thesis concludes with recommendations for changes which can 
enhance the use of the prototype from both a technical and managerial standpoint. 
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THESIS DISCLAIMER 



The reader is cautioned that computer programs developed in this research may 
not have been exercised for all cases of interest. While every effort has been made, 
within the time available, to ensure that the programs are free of computational and 
logic errors, they cannot be considered validated. Any application of these programs 
without additional verification is at the risk of the user. 
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I. INTRODUCTION 



A. PURPOSE OF THESIS 

The purpose of this thesis is to examine enhancements of the human interface to 
an interactive computer simulation program by applying computer graphics techniques 
to the interface. These graphics techniques are known as the visual interface and have 
found widespread applications in man-machine interaction. In this study the viability 
of applying such an enhanced interface to an existing application is based upon three 
factors: 1) The casual user of such an application does not have or maintain the 

necessary skills to efficiently utilize the application. 2) The technology which supports 
the enhanced interface has advanced past the technology of the current application's 
design since the design was frozen and implementation of the design into a finished 
product was begun. 3) The low cost of computer's with large amounts of memory and 
extremely capable CPUs has led to a proliferation of advanced microcomputers. Given 
these factors, the development of an enhanced interface is achieveable. 

The achievement of the enhanced interface requires a knowledge of background 
information about the interface subject. The subject is the Joint Theater-Level 
Simulation (JTLS) and it's user interface. By beginning with the purpose of JTLS and 
how it is utilized, the scope and organization of the research of this thesis may be 
established. The background information about JTLS and the scope of the research 
follow later in this section. Chapter 2 examines the current JTLS interface (the Model 
Interface Program), it's design and structure, it's current functions, and it's modus 
opercindi. Chapter 3 discusses the design of an enhanced interface, the correlation of 
the current interface with the enhanced version, the enhanced versions modus operandi, 
concludes with proposals and observations about various aspects of the enhanced 
interface development and utilization. Chapter 4 concludes the thesis with a 
summarization of the enhanced interface prototype design and it's usage. These 
sections How from the basic design and operation to an enhanced design and purported 
operation which is achieveable. The research begins with the background review of 
JTLS. 



9 



B. BACKGROUND 



The goals and scope of this thesis are predicated upon understanding the object 
examined. The nature of the object, it's reason for being to include a brief review of 
it's history, and it's present technical configuration provide a basic foundation upon 
which this research may be built. The object is JTLS and it's nature is that it is an 
interactive computer simulation model used for wargaming. The original objectives 
behind the design of JTLS and how those objectives have evolved are discussed to 
provide a link to future JTLS use. Finally, the present technical configuration of JTLS 
presents it's hardware and software elements which are the backbone of JTLS 
implementation. A more detailed discussion of these elements follow. 

Computer simulation is an ellective, economical method of analyzing military 
plans and operations without actually employing the military forces which carry out 
those plans and operations. It is possible, using computer-based simulation, to trace, 
in detail, the consequences and implications of a proposed course of action [Ref. 1: p. 
1-2]. One such simulation (or wargame) is the Joint Theater Level Simulation (JTLS). 

A complete set of manuals documenting JTLS, from it's inception to it's 
implementation, has been published. Much of the following background information is 
taken from the JTLS Executive Overview manual. JTLS is a computer-assisted 
wargaming system that models two-sided air, ground, and naval combat. It was 
designed for use in warfare training, joint operational planning, and doctrinal analysis 
with an emphasis on rapid production of results, theater-independence, and ease of use 
for non-programmers. The original design objectives of JTLS were to 1) provide a 
contingency planning analysis tool for the United States Readiness Command. 2 ) 
provide an educational wargame and analytic capability for the United States Army 
War College, and 3) provide an analytic tool aiding contingency plan evaluation for the 
United States Army Concepts Analysis Agency. 

In 1985, the Joint Analysis Directorate of the Organization of the Joint Chiefs of 
Staff assumed responsibility for the control and direction of future JTLS development 
efforts. (The Joint Analysis Directorate is now the Force Structure, Resource, and 
Assessment Directorate (OJCS/J8). This was done as part of a program to upgrade 
the analytic tools available to the unified Commanders in Chief for use in war 
planning. Included in their interests are future developments of JTLS which enhance 
user friendliness through advanced technologies such as the visual interface of window- 
management. 
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The need for enhancements to the human interface are due to the nature of the 
use of JTLS. As an analytic tool it is used sporadically to test doctrine, strategies, and 
tactics by a variety of users. Frequently, these users are not computer operators by 
trade nor do they spend many hours playing JTLS. Their primary interest in JTLS is 
the outcome based upon a preformatted and staged input to the game. They do not 
need a complicated, difficult to learn ( and easy to forget) computer simulation that is 
not readily usable when they are trying to develop and conduct an experiment with 
warplans. The Model Interface Program (MIP) can be such a program for the casual 
user. Unless the user frequently plays JTLS. the operation of the MIP is moderately 
difficult on which to maintain proficiency and it is not conducive to quickly 
resurrecting lost proficiency. 

The JTLS system is designed to operate on Digital Equipment Corporation's 
VAX minicomputer systems, including the 11/780, 11/785, and 8600 computers. The 
minimum hardware configuration for JTLS consists of four video terminals and one 
on-line printer. The maximum configuration consists of 28 video terminals. 10 graphics 
displays, and one or more line printers. 

The following support software is required to implement JTLS: 

1) A VAX/VMS operating system. 

2) A SIMSCRIPT II‘.5 programming language compiler. 

3) A "C" programming language compiler. 

4) An INGRES data base system. 

Most of JTLS is written in the computer language SIMSCRIPT II. 5 (a registered 
trademark of CACI, Inc.). The language is designed to facilitate the simulation of 
large, complex systems. The simulation constructs are embedded in the language, 
which is free-form and English-like. SIMSCRIPT II. 5® also has such automated 
features as statistics-gathering mechanisms, dynamic storage management, and flexible 
report generating. For these reasons and others, SIMSCRIPT II. 5® was selected as 
the high level programming language for the simulation applications. [Ref. 2] 

JTLS may be summarized as being a complex, sophisticated set of computer 
programs which may have more extensive capabilities when properly configured and 
used. With these facts about JTLS in mind, the examination of the player interface to 
the JTLS may be conducted. 
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C. SCOPE 



The Joint Theater-Level Simulation (JTLS) is an interactive computer simulation 
model used for wargaming of theater conflicts. The nature of a two-sided computer 
simulation, such as JTLS, is to produce an outcome as the result of the interaction 
between the two opposing sides. In this case, the two sides simulate combat by 
directing simulated military forces into proximity, with the result being an outcome of 
a battle. The whole impetus behind this simulation is the involvement of the player, 
i.e., the human interface. The main area of interest in this study is the Model Interface 
Program (MIP). It is through this program that the human interaction with the game 
is conducted and is what the prototype design will enhance. 

Several avenues of research may be taken to develop the aforementioned 
prototype. The method used here is to develop the prototype using as much of the 
existing MIP source code as possible. This approach provides an economical, quick 
ability to implement a full-scale visual interface. The efficiency of such a prototype 
compared to a total redesign of the MIP in terms of future expansions or computer use 
will not be addressed in depth. 

The general operation of a JTLS simulation is to conduct an interaction within 
the combat simulation by issuing orders to the available military forces. The Combat 
Events Program (CEP) compares the actions of the forces, within the limitations of 
their environments, and yields the results of the combat. As a result of the interaction, 
the commanders of the forces must continually make decisions during the course of the 
game. These decisions (the issuance of orders) are transmitted to the CEP via the 
Model Interface Prqgram (MIP). Thus, the MIP is an interactive program used by all 
players. 

The present version of the MIP, while fully capable of interacting with the CEP, 
is considered unwieldy for the occasional user, difficult to learn, and slow in terms of 
conducting a fast paced simulation. Of primary concern is the methodology of issuing 
orders to the CEP. While this methodology is examined in depth later in this thesis, it 
may be safely stated that the MIP lacks user friendliness for the occasional user and is 
not meeting current and future requirements for the purposes of player interaction with 
the game. 

One method of enhancing player interaction to JTLS is the use of the visual 
interface. The visual interface was borne out of the "need for creating easy-to-learn 
and easy-to-use applications" [Ref. 3], Some advantages of the visual interface are to 
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increase the data absorption rate by the user, reduce input/output errors such as those 
which occur during the typing of data, provide the user a "positive transfer of learning" 
to the new system, and the reduction of user anxiety caused by a lack of control or a 
lack of information [Refs. 4,5]. The visual interface simply allows the user to "see" 
what is going on; a much faster process than "reading" what is going on. 

Implementing the visual interface is done through a variety of computer graphics 
applications. The visual interface application examined in this thesis is that of window 
management. Window management deals specifically with the methods of creating 
graphical forms (windows), and displaying manipulating information within those 
windows. The Apple Macintosh 101 is an excellent machine for implementing the use of 
window management techniques in microcomputer application programs. 

The scope of this thesis will be to investigate the current methodology of creating 
a player order (a directive) and issuing it to the Combat Events Program(CEP), 
breaking down the methodology to create and issue the order, and reconstructing the 
methodology using the visual interface format. The particular case study will create an 
air directive, with it's associated utility directives, and send it to the game. In doing so, 
much of the material to follow will examine particular commands and directives as 
representative functions of the overall MIP. The methodology developed and used in 
the course of designing the prototype will be a useful tool in the expansion of the 
prototype to include all MIP functions in a Macintosh interface. In the opinion of the 
author, the basic constructs of the visual interface prototype should also be useful in 
the event of a total redesign of the MIP. The study begins with a detailed examination 
of the current Model Interface Program. 
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II. THE MODEL INTERFACE PROGRAM 



A. THE RELATIONSHIP BETWEEN JTLS PROGRAMS 

The JTLS Executive Overview addresses the overall structure of JTLS. The 
JTLS system consist of several independent programs which work together as a system 
of functions. The functional programs of JTLS are described below. The functional 
programs of JTLS have a variety of interrelationships as shown in Figure 2.1. It is 
through these relationships that the MIP initializes itself; obtains data from databases, 
files, records, and displays; and performs its functions. 

The functions of the Model Interface Program are: 

1) Entering orders. 

2) Processing orders. 

3) Communication between players and game controllers. 

4) Communication between the players and the combat simulation. 

5) Accessing and using support information. 

6) Saving directives in archive files. 

7) Analyzing post-processor data. 

8) Controlling graphics output. 

9) Stopping or temporarily halting the game. 

To accomplish any of these functions the MIP must depend on the other JTLS 
programs for support. For example, the CEP and Executive Program provide the 
information required by the MIP to create and process orders. The game's scenario 
database, which provides the players units, equipment, etc., is created by the Scenario 
Preparation Program. While the MIP does not communicate directly to ail JTLS 
programs, it does have an indirect relationship to those outlying programs. In concept, 
since the MIP is a critical function of the execution phase of JTLS, its importance 
demands the support of the other programs and, in turn, results in the relationships 
shown. [Ref. 2] 

B. THE MIP STRUCTURE 

The structure of the MIP can be derived from its functions, its relationships, and 
the high level language SIMSCRIPT II. 5® used to program the MIP. In deriving the 
structure, several system models were developed to express the why, what and how of 
the MIP. These models are discussed below. 
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Figure 2.1 Functional Programs of J'l'LS. 
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1. The Fundamental Model 

The overall system model is the fundamental model, Figure 2.2. In this model 
the various user inputs to the program are shown as well as the outputs of the 
program. Note that the functions are not delineated here since they are inherent to the 
MIP in this model form. The purpose of the fundamental model is to define the 
desired results and identify the necessary inputs while leaving the identification of 
specific contributors to any given function to the program. The "how" is examined in 
greater detail through data (low diagrams. 




2. The Data Flow Diagram 

The data flow diagram, Figure 2.3, displays the flow of information from the 

player to the game. Although not intricately detailed here, it does show the basic 

transformations which take place, what type of information is passed, and the location 
of sources or sinks of information. 

A significant portion of the flow of information from the player (the input) to 

the game (the output) deals with the directive. The directive is the heart of the game in 

that it literally causes an interaction to take place in the game thus producing some 
outcome. Without the directive, there would be no simulation model. Due to the 
directive's importance to this application, much of the design is described with the 
directive as it's focal point. To appreciate the directive's impact on the (low of 
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Figure 2.3 The Data Flow Diagram of the MIP. 

information, one must understand that most of the data is manipulated with the goal 
of developing and exercising a directive. 

At this point it is necessary to understand the performance of the various 
elements of the data flow diagram. In the case of the player creating an order, the 
player first enters a command. The transformation of the input is the performance of 
that command. If the command was a create command then the next transformation 
would build the directive using the attributes entered by the player. When all the 
attributes have been entered, the player enters another command to tell the MIP the 
directive is completed and to manipulate the directive. For example, this could be a 
verify , hold , save, or send command. Any command other than a send command would 
require the player to enter more commands before the directive could be sent to the 
CEP. When the player issues a send command, the directive is formatted into an order 
message the CEP can read and understand. The order message is then placed in the 
CEP's mailbox. 

A key issue here is that the player is constantly entering data directly into 
transformation modules without the data flowing in a "fluid" manner towards an 
output. The superimposed box outlines a bottleneck of data flow in the data flow 
diagram. This bottleneck places a great demand on the player to provide data in this 
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model. The source of the player's data is a computer printout of function specific 
information printed prior to playing the game. This is undesirable since all (or nearly 
all) of the data necessary for transformation during the creation of a directive is 
available in a database or file in the game itself. In particular, a file called the Player 
Initialization File (PIF) exists for each player and contains much of the information 
needed by that player to perform transformations, i.e., developing directives. Ideally, 
the transformation mechanism , vice the player, would do the work of sourcing and 
entering the data. Such a mechanism can be created using the graphics interface 
environment. 

3. The Data Structure 

The data structure of the MIP is a hierarchical system that is implemented by 
using multi-linked lists containing scalar items, vectors, and n-dimensional spaces. In 
SIMSCRIPT these concepts are established first as entities. These entities are 
characterized by their attributes. If there are logical associations or groupings of 
entities, they are described as sets. [Ref. 1: p. 1-15] 

A set is a logically ordered collection of entities organized through a system of 
set pointers. A pointer is the address in memory of a data item. For example, the 
MIP has a set of targets with pointers to (i.e. the addresses of) the first and last 
members of the set and the number of members (targets) in the set. Figure 2.4. These 
attributes of the set are considered to be owner attributes. Each member (target) has 
pointers to (addresses of) the preceding and succeeding members of the set as well as a 
flag to record membership in a set (to disallow multiple membership). 

Entities may be permanent or temporary. The permanent entities exist 
throughout the simulation unless they are explicitly destroyed. Temporary entities are 
those which are short-lived during the simulation or for which the number of copies 
varies within the execution of the simulation. 

Figure 2.5 shows an example of some permanent and temporary entities. While 
AIRCRAFT_(1) and AIRCRAFT_(2) exist in storage throughout the game, the 
RECOGXIZED_COMMAND is only put into storage at the time it is created. 

All of the data used in the game by the MIP is stored in these sets, entities, or 
attributes. Their definitions may be found in the MIP's source code preamble. All of 
the data needed to create player directives is found in these data structures (primarily in 
the PIF). However, the data structures aren't effectively used. This was demonstrated 
in an earlier section and will be discussed later in this thesis. For example, the 
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Figure 2.4 An Example of Set Organization. 




Figure 2.5 Examples of Entities. 

AWACS air directive only uses data from the permanent and temporary entities listed 
in Figure 2.6. The PIF's function here is simply error checking to ensure the data 
entered is correct with respect to the scenario's data. The poor use of the PIF results 
in the increased burden of furnishing data being placed upon the user. 
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Permanent Entities Temporary Entities 
Directive_Prototype Directive_ 

Attribute_Prototype 
Create_Routine 
Word Indicator 



NOTE: These do not include type 
checking, help, or graphics entities. 



Figure 2.6 The AWACS Directive Data Structure. 



C. THE MIP FUNCTIONS EXAMINED IN THIS PROTOTYPE 



1. The Commands 

The MIP has 36 commands which perform environmental, directive specific, 
or group of directives specific tasks for the player. These commands essentially 
instruct the MIP to take further actions which have been defined by the player to 
accomplish his decisions. The environmental commands perform the administrative 
tasks such as printing, spooling, scanning, finding, etc. The other two categories of 
conunands manipulate the directivc(s) by creating, changing, sending, etc. At times, 
the delineation of these commands into the three categories seems vague. However, 
this delineation will become clear later when the visual interface is applied to the MIP 
functions. 



The specific commands of interest and their definitions are as follows: 

• CREATE 'flic acute conunand allows the player to create a directive within 

the domain of the player's function. 

• GCREATE The gcreate command allows the plavcr to create a group of 

directives within the domain ol the player's function. 

• QUERY The query conunand allows the nlaver to request that the CEP send 

the plavcr standardized reports 'which pertain to the player s 
I unction. 



• FIND 1 he find command allows the plavcr to hold a directive that was 

previously in existence. 

• COPY The copy command allows the plavcr to create a directive whose 

attributes, except for the identifier, arc identical to those of an 
existing directive of the same tvpe. 
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• GCOPY 

• JOIN 

• LEAVE 

• GCLEAR 

• DISPLAY 

• GDISPLAY 

• MENU 

• SAVE 

• LOAD 

• TRANSMIT 

• SCAN 

• SPOOL 

• PRINT 

• REFRESH 

• SET 

• ADJUST 

• RETURN 



• SEND 



The gcopy command allows the player to create a group whose 
attributes, except for the identifier, are identical to those of an 
existing group. 

The join command allows the plaver to place a directive into a 
group. 

The leave command allows the plaver to remove a directive from a 
group. 

The gclear command allows the player to empty a group of all it's 
directives. 

The display command allows the plaver to see which directives of a 
particular tvpe have been created in the past and still exist, i.e.. 
have not been deleted. 

The gdisplay command allows the player to see which directives are 
in a particular group 



The menu command allows the plaver to view the menu of any 
existing directive without holding onto it. 

The save command records all of the players undeleted directives 
onto a file called the Archive File. 

The load command is used to brina directives from an Archive File 
into the MIP. 

The transmit command is used to transmit messages to other 
players. 

The scan command allows the player to view several messages in 
succession. 

The spool command allows the plaver to put several messages in his 
or. her print file without taking the 'time to examine them. 

The print command prints out a hard copy of all messaaes filed or 
spooled. 

The refresh command brings up a fresh VHP screen. 

The set command allows the plaver to set various parameters that 
tailor the use of the MIP to the player's liking. 

The adjust command allows the plaver to adjust the displav of his 
graphics station. 

The return command is used in conjuction with the exclamation 
mark to allow the plaver to use the OVERMIP feature. The return 
command convevs the player's intent to abandon the current 
overmip and resume action that the plaver had nreviouslv 
interrupted with the most recent exclamation mark. (NOTE: The 
OVERMIP feature freezes the current plaver action allowinc the 
plaver to perform some other action and then return to the point 
where the frozen action was interrupted. Not all plaver functions 
can be performed in the OVERMIP feature. ) 

The send command is used to send, the information contained in a 
directive to the CEP in the form of a plaver order. The command 
onlv applies to. the held directive, if there is one. (NOTE: The send 
coritmand applies onlv to action directives. Utilitv directives cannot 
be sent to the CEP explicitly; rather, the information contained in 
them is sent as part of the action directives that refer to them.) 
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• GSEND 



The gsend command is used to send, one at a time, all of the 
directives belonging to a particular group. 

• CHANGE The change command is used to change specific attributes of the 
held directive after its initial creation. 



• RESTORE 

• PAGE 

• VERIFY 

• G VERIFY 

• DELETE 



The restore command allows the player to override all change 
commands performed in the held directive since it was last held. 

The page command lists the menu of the held directive and, if the 
directive menu is contained on more than one page, it will cause the 
MIP to enter the paging mode. 

The verify command performs all validation checks not performed 
during tne creation of a directive or the changing of attributes. 

The gverify command performs the verify command for each 
directive in a particular group. 

The delete command permanently removes the held directive from 
the MIP. 



• GDELETE The gdelete command permanentlv eliminates a group of directives 
from the MIP. 



• DONE The done command returns the MIP to a state in which it is not 

holding any directives. 

2. The Directives 



The directives are essentially the actions the player wants to take in the course 
of playing JTLS. They tell the game what unit will take what action at what date; time 
with what resources. When the player begins to create a directive, a template appears 
on the terminal screen listing the attributes that comprise the directive. The directive 
template displays indicate if a data input for a particular attribute is optional or 
mandatory. 

While all directives contain attributes, those attributes only consist of a few 
basic types. The data input to those attributes are the distinguishing factors among 
directives. The most frequently encountered attributes are as follows: 

• REFERENCE A plaver selected name which uniquely identifies the 

directive. 



• UNIT, SQUADRON The name of the unit or air squadron being given the 

directive. 



• TIME The time for the directive to be implemented by the CEP. 

• DURATIONS The number of davs. hours, and or minutes the directive 

action is to be conducted. 



• COORDINATES The latitudes lonaitude pairs which indicate seoaraphic 

points ol interesls (for a variety of reasons) In the 
directive. 



• ROUTE, LOAD, LIST These are utility directives used as attributes in action 

directives. Thev must be created before an action 
directive may be'sent to the CEP and implemented. 



One extremely useful feature of JTLS is the ability of the graphics system to 
send names of units and targets and latitude/longitude points to the MIP. When 
graphics is used to enter any of these attributes, the MIP acts as if the player entered 
that data. A shortcoming of this feature is that the player has to establish a 
communications link between the MIP and the graphics station used. This must be 
done at both the player and graphics terminals. 
a. Creating the Action Directive 

To fully understand how the creation of a directive is accomplished, the 
reader should step through the process of directive creation. For example, the AIR 
player w r ould enter the create command. If the player didn't know the type of 
directives he or she could create or didn't know the proper syntax for the name of a 
directive, the player could enter a question mark (?). The MIP would then display a 
list of the air directives and associated utility directives. From that list the player 
would determine the type of directive to create, enter a "Q" to quit viewing the list, and 
when prompted, enter the name of the directive. 

Upon receiving the directive type, for example AWACS, the MIP would 
display the AWACS directive template on the terminal screen, Figure 2.7 . Of the nine 
AWACS attributes, three of them are utility directives. Five of the attributes have 
their data values checked for validity when the verify or send commands are entered to 
the MIP. As the player begins to enter data, each attribute is sequentially entered as a 
single entry or, for the expert player, as a stack of entries. At this point, close 
examination of the AWACS directive creation will show the reader what the MIP is 
doing during the process. 

The first attribute is the Mission. This must be a unique identifier to 
distinguish this directive from other air missions sent to the CEP. The MIP help 
function (the ?) describes the format for the identifier. When verifying or sending the 
directive, the MIP will check the identifier for uniqueness. 

The next attribute is the Squadron. This must be the name of a squadron 
type unit that the air player has under his or her auspices. Only a syntax check is 
performed here. 

Aircraft is the third attribute. This is a number that cannot exceed the 
number of aircraft in the squadron. The MIP will accept any value during data entry, 
but will match the value to the Squadron when the verify or send commands are 
entered. 
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1. MISSION: xxxxxxxx 




8. ORBIT LAT/LON: 


dd-mm-ssD ddd-mm-ssD 



2 SQUADRON: 

3 # AIRCRAFT: 



xxxxxxxxx 

nnnn 



9. SENSOR LIST: 



4. ROUTE IN: 

5. ROUTE OUT: 



(xxxxxxxx) 

(xxxxxxxx) 



6. ORBIT ENTRY TIME: ddhhmmZMMMYY 

7. ORBIT DURATION: ddDhhHmmM 



MIP COMMAND: CR AW 
MISSION. 



Figure 2.7 The AWACS Directive Menu. 

Route In and Route Out arc attributes which are utility directives. The 
data values of these attributes arc the names (identifiers) of routes created separately 
using the Air Route directive. These are checked to determine if the routes exist when 
the verify or send commands are entered. 

The Orbit Entry Time attribute is a time for the AWACS mission to begin 
surveillance in its flight pattern. It is entered as a date-time-group sometime in the 
future. When the game receives the directive it takes into consideration the time it 
takes for the aircraft to reach the orbit pattern and the time it takes to prepare the 
aircraft for launch when determining the validity of this time. If the squadron doesn't 
have enough time to prepare, launch, and flv the aircraft to the orbit pattern by the 
assigned time, the game will advise the player of that fact. The only real-time check is 
for syntax. 

The Orbit Duration attribute is a time which tells the game how long the 
aircraft will orbit in its pattern. This time is checked by the game by comparing it to 
the crew's maximum allowable flight time and advising the player if the duration is too 
long. The only real-time check is for syntax. 
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The Orbit Pattern is entered as a set of latitude/longitude coordinate pairs. 
The coordinate pairs determine the two end points of an elliptical orbit pattern. The 
only real-time checks are to determine if the points are on the surface of play and for 
syntax. 

The Sensor List is a utility directive. The data value of this attribute is the 
name (identifier) of a list of sensors to be loaded onto and used by the aircraft. The 
sensor list directive is created separately. The attribute is checked to determine if the 
list exists when the verify or send commands are entered. Since this is also the last 
attribute, the player must enter some command to manipulate the directive. It must be 
noted that this is the "held" directive until the directive is manipulated in some manner 
which "unholds" it. 

b. Creating the Utility Directive. 

Utility directives, as previously mentioned, are created separately from 
action directives. They must exist when the player attempts to verify or send to the 
CEP a directive which references them. There are two avenues to create a utility 
directive. One is to create the directive when the player has a blank screen. The other 
is to use the OVERMIP feature while creating an action directive, suspending the 
player's interaction with the action directive, and allowing the player to then create the 
utility directive as if a blank screen existed. 

The Air Route directive has two apparent attributes as shown in Figure 2.8. 
One is the Route ID which is unique to that route. The other is the Latitude and 
Longitude. This coordinate pair is entered for every point of the air route except the 
origin. A null entry (NE) is entered after the last pair. The MIP then prompts the 
player for altitudes for each point. Altitudes are from 500 to 60,000 feet. A null entry 
is then used to quit. 

The Sensor List directive, Figure 2.9, specifies the sensors to be included in 
a particular sensor package configuration used for various air directives. The two 
attributes of this directive are the List ID and Sensor. The List ID is the unique 
identifier of that list. The sensor is a category of sensors which indicate which type of 
sensors to put into the list. A null entry is used to quit. 

3. Summary’ 

This section has described the relationships between the programs which 
constitute JTLS, the structures of the Model Interface Program, and the MIP functions 
to be examined in the prototype. One very’ important aspect of JTLS which will have 
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MIP COMMAND: CR ARTE 
ROUTE D: 



Figure 2.8 The Air Route Directive. 
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Figure 2.9 The Sensor List Directive. 
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an impact on the approach to development of this prototype has not been addressed. 
That is the operating system and sequence of execution in SIMSCRIPT II. 5® The 
foundation of the SIMSCRIPT system and the sequence in which JTLS (and the MIP) 
source code is executed is the basic timing routine inherent to SIMSCRIPT, Figure 
2 . 10 . 

Execution of a SIMSCRIPT program begins with the first statement in the 
MAIN program and continues through a series of steps. Resources must be created 
and initialized before they are used by processes. Then the initial processes are 
activated in MAIN (since SIMSCRIPT requires that something be awaiting execution 
before a simulation commences). A simulation begins when control passes to a system- 
supplied timing routine. This is done by executing the START SIMULATION 
statement. The significance of "something must be awaiting execution" is understood 
when the main program is examined. 

The MAIN Program contains several processes. One of these is the terminal 
process. This process is literally the keyboard read process, i.e.. how the player inputs 
data through the keyboard to the MIP. When the player uses the keyboard, the 
process is activated. In terms of the timing routine, this means that the process is 
placed on the pending list and is executed by the timing routine. WTien the player's 
keyboard is idle (the player has used the return key to enter something), the process is 
not on the pending list and the timing routine waits for another process to be placed 
on the pending list. During this idle time, the MIP (and operating system) are 
essentially waiting for the player to do something in the interactive mode. Here the 
MIP can still be performing some non-interactive tasks. The significance of this idle 
time created by the MIP is a temptation to the designer to interface directly with the 
MIP rather than the system. It will be demonstrated in Section III that this is not a 
particularly effective approach for development of this prototype. 

D. A COMPARISON OF SOURCE CODE VERSIONS 

To further illustrate the operational behavior of the Model Interface Program, a 
comparison was made between the current version of the MIP source code and the 
source code of a prototype version. In the comparison, a particular objective was 
selected to be accomplished by the source code. Both versions of source code began at 
the same point and finished with the same result. The current version is written in 
SIMSCRIPT while the prototype version is written in Pascal for operation on the 
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START SIMULATION 




Figure 2.10 The Basic Sl.MSCRIPT Timing Routine. 
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Macintosh. Tables 1, 3, 5, and 7 are the current versions of source code for steps 1-4 
respectively. Tables 2, 4, 6, and 8 are the respective prototype versions of source code. 
There are several noticeable differences between the two sets of source code. These 
differences will be pointed out in the following narrative. 

The comparison was made using the creation of a Sensor List directive as the 
objective of the source code. Both versions of source code begin that process at the 
point where the player must select the directive type. The process then is broken down 
into a series of steps. Step 1 is to select the type of directive to be created. In this 
case, Sensor List is selected. Step 2 is to display the directive on the screen. Step 3 is 
to assign an identification reference to the directive. Step 4 is to assign sensor 
packages to the sensor list. The process ends at this point. From here, for example, 
the player could save, verify, or send the completed directive. 

It should be noted that in the current version the steps must be taken in strict 
sequence. The prototype version permits the reversing of sequence order for steps 3 
and 4. The order of sequence is left strictly to the player's discretion as to what step to 
do when. The player can even go back and redo a step in the prototype version. This 
is not permitted in the current version. To do so the player must exit this process after 
it is completed and begin a totally different process. 

A significant assumption was made regarding this process. This should be noted 
so the reader may gain a greater appreciation for the results of the comparison. First, 
it is assumed that the player will always enter syntactically correct, accurate data. 
Thus, format’ and type checking source code has been left out of the example in the 
current version. The prototype incorporates the checking into its code due to the 
nature of its operating system. Except for one case, no prototype case requires any 
explicit checking. 

It was also assumed that the player would not abort the process. The current 
version source code to do this was also left out. The prototype version did not require 
explicit code as this is inherent to the operation of the system. Also, any code dealing 
with error messages to the player was deleted from the listings. The current version 
has quite a few error messages while the prototype version would only require one for 
this process and its message is inherent in the operating system. The "help command" 
code was also omitted from the current version. It literally is not needed in the 
prototype version. 
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A readily evident result of the comparison now exists and should be mentioned 
despite the risk of prejudicing the overall outcome. The result is that quite a reduction 
of source code can apparently be made between the two versions in the areas of 
checking, process abort, and error messages. This is not a hard and fast result in the 
final outcome however. The reduction in source code now may be offset by an 
increase in code to perform other functions later. It is the opinion of this author that 
this will not be the case. 

1. Step 1 

The process of selecting the directive type is straight forward. The presentation of 
information to the player requesting a selection is quite different. The current version 
presents a blank screen in the content region (the middle of the screen) while the scroll 
area (the bottom portion of the screen) contains the prompt "directive type:" with a 
blinking cursor a few spaces to the prompt's right. Here the player would begin the 
process by typing in the words "sensor list". The prototype version presents the player 
with a box in the middle of the screen. The box contains a list of directive types which 
are currently available to the player. The player moves the cursor to the "sensor list" 
item in the list and selects it. 

♦ 

The determination of what type of directive to create has been completed. 
The type selected in both versions was the Sensor List. A breakdown of the step 
reveals several interesting contrasts between the versions. The- first is the display itself. 
The current version puts it's information for the player near the bottom of the screen. 
While it is out of the way for the main portion of the screen, it is also "out of the way" 
in terms of the player's visual focal point. In general, a person's initial focal point is 
the middle of a display and then the person examines the display area to seek out the 
required information. 

The prototype version places it's display in the middle of the screen which is the 
player's initial focal point. The player doesn't have to search for the information. This 
contrast is subtle, but nonetheless significant throughout the process and in terms of 
information transfer to the player. 

The player's actions also represent a contrast worth review. The current 
version requires the player to type in characters from the keyboard. The prototype 
version requires the player to position the cursor and press a button (an item click), an 
action which is always at the player's fingertips. The two actions are quite different 
and ease ot performance for typing varies significantly from player to player. The 
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TABLE 1 

STEP 1 - CURRENT VERSION 



Determine . the .Directive .Type 
Use 55 for input 

Let prompt. v = "Directive Type:" 

Now Interpret . the. Directive .Meaning 
Given 100 
Yielding meaning 
CC_number = 100 

Find the first Command_Context(CC_Number) in Vocabulary_ 

Do until terminated 

Now Determine . the .Response 
Until finished do 

If Input_Line is not empty 
Use buffer for input 

Remove first Input_Word from Input_Line 
Let Response_ = upper. f(lW_Text( Input Word)) 

Let Last. Source = IW_Source(Input_Wora) 

Destroy Input_Word 
Return 

Else If Last. Source * 0 

If Last. Source = I. Terminal 
Activate Terminal Process 
Else use 55 for input 

Now Write. A. Text. String 

Given prompt. v, 23, 1, 0, 0 
Use buffer for input 

Activate Graphics Process 
Suspend c 

Loop 

IF Directive_ * 0 
Now Display. a. List 
Given Dir_Menu, 2; 

Let Menu_Status = "display" 

Let Lines = Dim. f (Dir Menu(*)) 

Let lines .per .page = Tines-2-2 
If lines' S 15 

For I = 1 to lines do 
Now Write. a. Text. String 

Given Dir_Menu(I), 2+1-1, 1,0,0 
Call LIB$Put_Screen(Descr.F(Text. String) , 
line+1 , column, local . graphics) 

Return 

Let Menu_Status = "menu" 

For each Recognized_Command in CC_SET_OF_ENTRIES (CC_Number) 
With RC_Name = "Sensor List" or RC_Alternate_Name = "SL" 
Find the first case 

Let meaning = RC_Meaning_No (* = 706 *) 

Return 



preference of one action over the other varies according to the individual's tastes. 
These two contrasts are again subtle but their significance, especially typing, is closely 
tied to an individual's physical skills. 
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TABLE 2 

STEP 1 - PROTOTYPE 



ModalDialog(NIL, theltem); 

11 := GetDItem (theDialog, theltem. Handle, Display); 

12 := GetNewControl (II, theDialog); 

DPLongName := GetCTitle (12, title); 

DisposDialog (theDialog); 



The most significant contrast is in the source of the data. The current version 
requires the player to be the source of data and it is entered via the keyboard. The 
prototype version provides the source of data (in all but one case) via computer 
memory’ with input made through the item click. Since the input is made through 
computer memory' there is no chance of a syntax error and less of a burden upon the 
player to enumerate the choices of directive types available to him. The prototype 
enumerates the choices and makes a syntactically correct entry of data to the process. 

In summarizing the contrasts of versions in the first step, it is worth noting 
the amount of source code required to perform the step. The prototype performs the 
same step with only an estimated 15% of the source code needed in the current 
version. The primary difference in the amount of code’ is due to the large amount of 
current version code required to display, retrieve, and interpret information written to 
the screen from the keyboard. The prototype version gains this advantage by using 
operating system functions and procedures to perform comprehensive accomplishment 
of tasks. Another reason is that fewer tasks are required in the prototype version due 
to the nature of the operating system. It will be evident as the process continues that 
the contrasts of display, player actions, and source of data will be factors in each step 
of the process. The reader is cautioned that task accomplishment may not always be a 
prototype advantage in the performance of the process. Now step 2 is ready to be 
done. 

2. Step 2 

This step in the process displays the directive Sensor List on the screen. The 
display includes the directive title, the directive's attribute and the attribute's field 
codes. The display is oriented toward the middle of the screen on both versions' 




TABLE 3 

STEP 2 - CURRENT VERSION 



For each Directive_Prototype with DP_Meaning = 706 
Find the first case 
Now Create . the .Directive 
Now Erase . the .Menu. Area 
For I = 3 to 17 

Call LIB$ERASE_LINE ( I , 1) 

Let Menu^Status = "blank" 

Create a Dfrective_ 

Store Directive_Prototype in O.DP_Directives_Set 
Reserve Menu Array as size = 15 
Store DP_Menu_Template in Template Array 
For I = 1 to 15 

Let Menu(I) = Template(I) 

Store Menu(l to 15) in Dir_Menu 
Now Display. a. List 
Given Menu(l), 2 
Let Menu_Status = "display" 

Let lines = Dim.F(Menu(I)) 

Let lines .per .page = 18-2-2 
If lines S 15 
For I = 1 to 15 

Now Write . a .Text . String 

Given List(I), 3+1-1, 1, 0, 0 

Call LIB$Put_Screen(Descr.F(Text. String) , line+1 , • 
column, local. graphics) 

Return 

Let Menu Status = "menu" 



display layout. In both versions the step begins with a directive meaning and then 
searches the data structures for a directive prototype having a meaning of "sensor list". 
When the code finds that data, it displays it on the screen. At this point the versions 
begin to differ. 

The current version first calls a VAX library routine to erase the screen. It 
then develops a generic display template consisting of 15 lines. Once the template is 
made, the current version gets each attribute of the directive prototype and draws it to 
the screen, line by line, according to the AP_Line and AP_Coll values of each 
attribute. When each line is drawn the display is complete. 

The prototype version begins by creating a pointer to a new directive and then 
invoking the directive display module. Every directive reads in a generic display 
template and, for each display control item, changes the control's generic title text to 
the attribute's menu prompt. At the same time each control item is changed, it makes 
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TABLE 4 

STEP 2 - PROTOTYPE 



For Directive Prototype with DPLongName do 
NewDirective = "[Directive; 

Directive Display; 

N := NumberAP; (* the total number of attributes *) 

For I = 1 to 12 do 

GetNewControl(ID, theWindow); 

For J = 1 to N do 
If I = J then 

SetCTitle(J, AP Prompt); 

ShowControl (J); 

Else For I > N do 

For DP Attribute Prototype (I) do 
HideControl(I) ; 

HiliteControl(I , 254) ;(* disables control *) 
DrawControls( theWindow) ; 



it visible. For each control item not changed that control item is made invisible and 
inactive. The module then draws the display to the screen in its completed form. 

The contrasts here are speed and amount of code. The speed is 
inconsequential here since the prototype uses the same repetitive loop as the current 
version to produce the display. However, speed could be tilted considerably in favor of 
the prototype version if each specific directive display existed in a resource file and was 
explicitly called when needed. This would result in a much faster time for the 
Macintosh to draw the display to the screen (this will be discussed later in this thesis). 
The current version has no capability to do this. 

The other contrast, amount of source code, again favors the prototype 
version.' The reduction of an estimated 35% of the current version is primarily due to 
graphics overhead on the VAX. For example, a repetitive loop is used to erase the 
VAX screen line-by-line, another loop is used to create the display template line-by- 
line, and finally a repetitive loop is used to draw the display. The prototype version 
uses a single, doubled-nested repetitive loop to assign text to display items and then 
draw the display to the screen. The ability of the prototype to do this in a simpler 
manner than the current version is owed to the operating system functions and 
procedures comprehensively performing tasks. 
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The summary of contrasts for step 2 again results in a favorable rating of the 
prototype over the current version. This leads to step 3. Although the prototype 
version would permit the execution of step 4 at this time, for simplicity in conducting 
this comparison, both versions will perform the same step. 

3. Step 3 

This step deals with getting an ID for the directive. Keeping in mind it must 
be unique, the assumption made here (for simplicity) is that the player will enter a 
unique ID. In this step both versions differ from the start. Here the prototype version 
waits for an event to occur while the current version must write the prompt to the 
screen. The advantage is immediately tilted toward the prototype version. The process 
will indicate why. 

The current version begins by sequentially stepping through the attributes and 
stops at the first one. It reads the AP_Menu_prompt, "1. List ID:", and rewrites it 
over the existing "1. List ID" but this time emphasizes it graphically. It then draws 
the AP_Create_Prompt, with a flashing cursor as emphasis, into the scroll area at the 
bottom of the screen. Then, invoking the attribute's create routine, it awaits the 
player's keyboard response. Once the player inputs a string, the current version checks 
to make sure it is not more than 8 characters. If it is more than 8, an error message is 
generated and the prompt in the scroll area is rew r ritten. (This check was intentionally 
left in the process due to its significance in the comparison.) If the response is 
acceptable, it is written into the field code space replacing the attribute field code. The 
current version then deemphasizes the AP menu prompt and then invokes the Retrieve 
the Directive Attributes module. Here it reads the attribute's word_integer and assigns 
the ID to the appropriate word in Directive_. 

The prototype version begins by waiting for a player action known as an 
event. In this case, a click in the "1. List ID:" item. The prototype version determines 
an event occurred, what to do to handle the event, finds out the location of the click 
event, and then invokes the CRRGet module for the given AP Create Routine. Now 
the prototype gets a dialog box and draws it in the center of the screen. The dialog 
box includes a text edit rectangle, 8 spaces long, with a flashing cursor in it. Now the 
prototype waits for the player to input a string, which is also another event. It 
determines an event occurred, that it was a keypress event (of a legal character), and 
enters the character string into the text edit rectangle. Note that since the text edit 
rectangle is only 8 spaces long it implies the player can never enter a string that is too 
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TABLE 5 

STEP 3 - CURRENT VERSION 



For each Attribute.Prototype in DP.Attributes.Sett Sensor.List )Do 
Use 55 for input 

Let prompt. V = AP.Create.Prompt (* "List ID:" *) 

Use buffer for input 
Now Write. a .Text .String 

Given AP.Menu.Prompt , AP.Line, AP.Coll, 0, Emphasize. 

Call LIB$Put.Screen( Descr. F( AP.Menu.Prompt ) , AP.Line, AP.Coll, 

0, Emphasize.) 

Write AP_Arguments_String as text 

Let Subroutine = CRR_Name( AP.Create.Rout ine ) 

Call Get. a. Directive. Identifier 
Read Search. Code 
Until finished do 

Now Determine. a. Response 
Until finished do 
If Input.Line is not empty 
Use buffer for input 

Remove first Input.Word from Input.Line 
• Let Response. = Upper . F( IW_Text( Input.Word ) ) 

Let Last. Source = IW_Source( Input.Word ) ) 

Destroy Input.Word 
Return 
Else 

If Last. Source * 0 

If Last. Source = I. Terminal 
Activate Terminal Process 

^ Else use 55 for input ♦ 

Now Write. a .Text . String 

Given prompt. v, 23, 1, 0, 0 
Use buffer for input 

Activate Graphics Process 

Suspend 

Loop 

If Response. = "NE" 

Now write. a .Bottom. Line 

Given "A null entry is not valid" 

Call LIB$Set_Cursor( 24, 1) 

Call LIB$Put_Screen( Descr. F( Concat . F( text . string, CR.LF ) ) , 
24, 1, 0) 

Now Skip. Rest. Of .Line 

For each Input.Word in Input.Line do 
Remove Input.Word from Input.Line 
Destroy Input.Word 
Loop 
Cycle 
Otherwise 

If Length. F( Response. ) > 8 
Now Write. a Bottom. Line 

Given "ID can be no more than 8 characters" 

Call LIB$Set_Cursor( 24, 1) 

Call LlB$Put.Screen( Descr. F( Concat . F( text. string, CR.LF)), 
24, 1, 0) 

Now Skip . Rest .Of . Line 

For each Input.Word in Input.Line do 
Remove Input.Word from Input.Line 
Destroy Input.Word 
Loop 
Cycle 
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TABLE 5 

STEP 3 - CURRENT VERSION (CONT'D.) 



If Length. F( Response^) ^ 8 

For I = 1 to Length. F( Response_ ) do 

Let This. Char = Substr. F( Response_> I, 1) 

If This. Char = or This. Char = 

Write This. Char as /> 

"Entry cannot contain" This. Char "character" 

Read Output. Line 
Now Write. a Bottom. Line 
Given Output. Line 
Call LIB$Set_Cursor( 24, 1) 

Call LIB$Put_Screen( Descr . F( Concat. F( text . string, CR_LF ) ) > 
24, 1, 0) 

Now Skip . Rest .Of . Line 

For each Input_Word in Input_Line do 
Remove Input_Word from Input_Line 
Oestroy Input_Word 
Loop 

Let Bad. Char = 1 
Leave 

Loop 

If Bad. Char = 1 
Bad. Char = 0 
Cycle 

Write Response^ as text 
If Menu_status = "menu" 

^ Now Write . a .Text .String 

Given Response_, AP_Line> AP__Col2, 8, 0 
Call LIB$Put_Screen ( Descr . F( Response ) , 

AP_Line, AP_Col2, 8, 0) 

Now Rep lace . the . Menu .Field 
Given Response^ 

Now Write. a. Text. String 

Given AP_Menu_Prompt , AP_Line, AP_Coll, 0, 0 

Call LIB$Put_Screen( Descr. F( AP_Menu_Prompt ) , AP_Line, 

AP_ Coll , 0, 0) 

Now Retrieve. the . Directive. Attributes 

For each Word_Indicator in Word_List( Attribute_Prototype ) do 
Case of (WI_Integer) 

(1) Read Dir_I0 
Loop 

Loop (* to do next attribute *) 



long and thus never commit an error. The transparent error checking will not accept 
the player's entry of an illegal character or more than 8 legal characters. The dialog 
box then assigns the AP field code the value of the string, moves the graphics pen to 
the field code space on the screen, and draws the string in as the field code. The 
prototype version then invokes Retrieve the Directive Attributes, reads the attribute's 
word integer, and assigns the ID to the appropriate word in Directive. 
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TABLE 6 

STEP 3 - PROTOTYPE 



GetNextEvent( theEvent, everyEvent) ; 

MouseClick; 

HandleEvent ; 

HandleClick; 

K := FindControl(thePoint, theWindow, 
whichControl) ; 

For DP Attribute Prototype (K) do 
L := AP Create Routine (K): 

CRRGet (L); (* Get an ID *) 

DialogPtr s= GetNewDialog (ID, dStorage, 
theWindow) ; 

TEPtr := TENew (destRect, viewRect); 

GetNextEvent; 

Keypress ; 

HandleEvent ; 

TEKey(Key , TEPtr); 

ModalDialog( thelDFilter , ItemHit) ; 

thelDFilter (theDialog, theEvent, ItemHit); 
thelDFilter := False; 

ItemHit : 0; 



If Length. F(string) ^ 8 then 
Case theEvent. What of 
Keydown, Autokey : 

Case of (theEvent. Message mod 258) of 

(1) (A..Z, 0..9, bkspc) : 

(2) NOT (A..Z, 0 . . 9 , bkspc) : 

thelDFilter := True; 
SystemBeep; 

Return; 

Else (* for Length. F(string) > 8 *) 

If theEvent .Message mod *256 = bkspc then 
thelDFilter := False; 

Else the IDFilter := True 
SystemBeep ; 

Return: 

DisposDialog( theDialog) ; 

MoveTo(AP Line, AP Co 12); 

to pixel units *) 

DrawString(AP Field Code (K)); 

Retrieve Directive Attributes; 

For Q = Word Integer do 
Case of Word Indicator 

DirlD := AP Field Code(K); (* Q = 1 *) 



(* AP Line & AP Col2 converted 



In this step the contrast focuses on the extra code required by the current 
version to do the process, the display of the focal point, and ease of input for the 
player. Once again the advantage pendulum has swung over to the prototype version. 
The first contrast deals with the fact that the current version is constantly doing 
graphics tasks of emphasizing, changing, and rewriting. The fact this is done so many 
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times encumbers the process in the current version while the prototype version 
performs it's tasks once. The prototype version reduces code execution an estimated 
58% from the current version. 

A significant contrast is the display focal point. Again the prototype version 
centers it's focal point immediately grabbing the player's attention. The current 
version creates two focal points which could be distracting. The first focal point is the 
emphasized attribute positioned in the mid-upper left portion of the screen. The 
second focal point is the prompt and cursor down in the screen's scroll area. This is 
really where the player wants to focus his attention. The advantage regarding this 
contrast is with the prototype version. 

The final point in contrasting the versions is the ease of player input. In the 
prototype version the player had to select the attribute himself vice having it done for 
him automatically in a predetermined sequence. This is fairly negligible when 
compared to the actual entry of data such as the ID string. Here the prototype 
ensured the player kept the ID within limits while the current version could permit the 
player to commit an error. This subtle contrast favors the prototype version. 

Finally, both versions are ready to enter their list of- sensor packages. 
Considering the wide margin of advantage of the prototype version compared to the 
current version, the final outcome of the comparison could be predicted. However, 
step 4 should be examined to complete the process comparison. 

4. Step 4 

This step is a lengthy process for both versions of source code. Similar 
processes occur in that both invoke the appropriate create routine, get the sensor 
package names and display all of them, and invoke Retrieve the Directive Attributes. 
The similarities end there. 

The current version expends a lot of code doing graphics displays, 
emphasizing, writing prompts, determining responses, rewriting prompts, and 
deemphasizing. In the end, the current version uses two focal points (moving back and 
forth between the two points), forces the player to explicitly input whether or not a 
displayed sensor package is assigned to the list, and requires the player to explicitly 
close out the list of sensor packages. 

The prototype behaves as expected. It waits for an event, in this case the 
click of the item "2. Sensor", draws a dialog box onto the center of the screen with all 
the sensor package names included in the box. It also invokes the List Control module 
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TABLE 7 

STEP 4 - CURRENT VERSION 

Use 55 for input 

Let prompt. V = AP_Create_Prompt 

Use buffer for input 

Now Write. a .Text. String 

Given AP_Menu_Prompt » AP.Line > AP.Coll, 0, Emphasize. 

Call LIB$Put_Screen( Descr . F( AP.Menu.Prompt ) > AP_line> AP_Coll> 0> 
Emphasize.) 

Write AP.Arguments.Str ing as text 

Let Subroutine = CRR_Name( AP.Create.Routine ) 

Call Get. a. Sensor .List 
.If Saved. Flag = 0 

Let Saved. Flag = 1 
Create Command.Context 
Let CC.Number = 1120 

Let CC.Message = "Enter (something) or NE to end list." 

For each Sensor.Package 
With SP.Name * " " do 
Create a Recognized.Command 
Let RC.Name = "NE" 

Let RC_Meaning.No = 100 

File Recognized.Command in CC.SET.OF.ENTRIES 
File Command.Context in Vocabulary. 

Store Dir.Menu in Menu (1 to 15) 

Let Menu.Status = "list" 

Let Line = AP.Line + 2 
Let Items . irv. List = 0 
Until finished do 
If Line =18-2 

Let Line = AP.Line ♦ 2 
Use 55 for input 

Let prompt. V = "Name of category:"- 
Now Interpret . the .Vocabulary . Entry 
Given CC.Number “ 1120 
Find Command.Con text ( 1120 ) 

Until finished do 
Now Determine . the . Response 
Until finished do 

If Input.Line is not empty 
Use buffer for input 

Remove first Input.Word from Input.Line 
Let Response. = Upper . F( IW.Text( Input.Word ) ) 

Let Last. Source = IW_Source( Input.Word ) ) 

Destroy Input.Word 
Return 
Else 

If Last. Source * 0 

If Last. Source = I. Terminal 
Activate Terminal Process 
Else use 55 for input 

Now Write. a .Text. String 

Given prompt. v, 25 > 1> 0> 0 
Use buffer for input 

Activate Graphics Process 

Suspend 

Loop 
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TABLE 7 

STEP 4 - CURRENT VERSION (CONT'D.) 

If Q = 1 

Let Q = 0 
If Directive_ ^ 0 
Now Display .a . List 
Given Dir_Menu> 2 
Let Menu_Status = "display" 

Let Lines = Dim. F( List( * ) ) 

Let Lines. per. page = 14 
If Lines < IS 

For I = 1 to Lines 

Now Write. a .Text .String 

Given List(I), 3+1-1, 1> 0> 0 

Call LIB$Put_Screen(Descr.F(List(I))> 3+1-1 > 1, 0, 0) 
Return 

Menu_Status = "menu" 

For Recognized_Command if CC_SET_OF_ENTRIES( 1120 ) 

With RC_Name = Response^ or RC_Alternate_Name = Response_ 

Find the first case 

Let meaning = RC_Meaning_No 
If meaning = 100 
Leave 

Let Substr. F( Menu_( Line-1 ) > AP_Coll, 15) = SP_Name( meaning ) 

Now Write. a .Text .String 

Given SP_Name( meaning ) , line, AP_Coll, 15, 0 

Call LIB$Put_Screen( Descr . F ( SP_Name ) » line, AP_Coll, 15, 0) 

Let Items . in. List = 1 
Create an Element_ 

Index ( Element_ ) = meaning 
File Elements in Vector^ 

Add 1 to line 
Loop 

Reserve Rarray( * ) as N.Sensor_Package 
Reserve TArray(*) as N.Sensor_Package 
Let Categories .per .page = 18-4-3 
For each Sensor_Package with SP_Name 2 " " 

Add 1 to Total .Sensor .Packages .On. This .Side 
Add 1 to Sensor. Packages. On. This. Side 
For each Element_ in Vector_ 

With Index( Element_ ) = Sensor_Package 
Find the first case 
I f found 

RArray( Sensor_Package ) = 1.0 
TArrayt Sensor_Package ) = "yes" 

Else 

TArrayt Sensor_Package ) = "no" 

If Sensor . Packages .This .Side ^ Categor ies . Per . Page 

Let Substr . F( Menu( AP_Line+Sensor. Packages .This. Side ) , 

AP_Coll , 15) = SP_Name 

Let Substr . F( Menu( AP_Line+Sensor. Packages . This .Side ) , 

AP_Col2 , 3) = TArray 

Loop 
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TABLE 7 

STEP 4 - CURRENT VERSION (CONT'D.) 



Let Header = ITOT.F(N.Sensor_Package) 

Write Header as text 
For each Sensor Package 

Write RArray(Sensor_Package) 

Release RArray(*) 

Now Empty . the .Vector 

For each Element_ in Vector_ do 
Remove Element_ from Vector_ 

Destroy Element_ 

Now Write .a. Text. String 

Given AP Menu_Prompt, AP_Line, AP_Coll, 0, 0 
Call LIB$Put_Screen 
Now Retrieve . the .Directive .Attributes 
Given WI_Integer 
Case of (WI_Integer) 

(53) Read Dim 

Store 0 in Real_Array(Dim) 

Reserve Real_Array(Dim) 

For I = 1 to Dim 
Read Real_Array(I) 

Store Real_Array(*) in Dir_Genericl_DPointer 
Cycle 



assigning each package a check box control. It then waits for the player to "check" (an 
item click) the sensor packages to be listed. The prototype version automatically 
determines that non-checked sensor packages do not go into the list and automatically 
closes out the list. It then assigns attributes to the appropriate words in Directive the 
same as the current version does. 

The Sensor List directive is now complete. Again contrasts between the 
versions gives the prototype the advantage. Amount of code, display focal point, ease 
of input for the player constitute the areas of difference between the two versions. 
Amount of code contrasts resulted in the prototype version having an estimated 65% 
reduction in lines of code executed from the current version. Repetition of graphics 
code and use of numerous data structure elements not required in the prototype 
account for the difference and the poor rating of the current version. 

The focal point of the display heavily favors the prototype version. It's 
display is centered on the screen and behaves exactly as the other prototype displays. 
The current version, on the other hand, continually switched the focal point of the 
player's attention from mid-screen (to see what was displayed) to the prompt in the 
scroll area (to make an input). This is distracting and time consuming. 
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TABLE 8 

STEP 4 - PROTOTYPE 



GetNextEvent 

MouseClick; 

HandleEvent; 

HandleClick; 

K := FindControl(thePoint, theWindow, 
whichControl) ; 

For DP Attribute Prototype (K) do 
L := AP Create Routine (K); 

CRRGet (L) ; (* get a sensor package *) 

List Control(ME); 

DialogPtr := GetNewDialog(ID, 
dStorage, theWindow); 

Until Sensor Package EOF do 
M := SP number; 

SetIText(M, SP Name); 

Repeat; 

For P := 1 to M do 

ModalDialog(NIL , theltem(P)); 

11 := GetDItem( thedialog, theltem. 

Handle, Display); 

12 := GetNewControl(Il ,theDialog) ; 

AP Field Code (index) := GetCTitle ( 12 , 
title) ; 

MoveTo(AP Line + 1 line, AP Col2 + 

4 spaces); (* lines & spaces converted 
to pixel units *) 

DisposDialog(theDialog) ; 

Index := Index + 1; 

Retrieve Directive Attributes; 

For Q = Word Integer do (* 0 = 53 *) 

Case of Word Indicator (Q) 

For Dim = 1 to M do 

For Num = 1 to Index do 

If Sensor Package (Dim) = AP Field 
Code (Num) then 
Real Array (Dim) := 1.0; 
Tarray(Dim) := ''Yes"; 

Else 

Real Array (Dim) := 0.0; 

TArray := "No"; 

Dir Genericl DPointer := JReal Array; 
For Set of Directives 
with DP Meaning = Sensor List(meaning) 

|Set of Directives := NewDirectiveT.Directive ; 



The final contrast is ease of use for the player. The player enters data through 
the keyboard, is subject to committing errors, and must make repeated inputs when 
using the current version. The prototype version only requires item clicks by the 
player; no errors, no distractions, just a simple process. The advantage here again 
heavily favors the prototype version. 
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In summarizing the entire process, a simplified one at that, the prototype 
version is distinctly easier to use for the player, a considerable savings of executed 
source code, and a better presenter of information than the current version. Based 
upon these comparisons of the two versions the creation of a graphically oriented 
replacement for the MIP is desireable. The following material is predicated upon the 
design of such a prototype. 
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III. THE PROTOTYPE OF THE VISUAL INTERFACE 



A. THE METHODOLOGY OF DESIGN 

1. The Basics of a Window Management System 

Window management systems are relatively new to computer systems, just 
barely a decade old. The computer industry as a whole did not accept window 
management from the outset, but people interested in computer graphics have kept the 
concept alive. Attempts at widespread usage of window management systems failed 
until Apple introduced their Macintosh. The Macintosh has gained widespread 
acceptance- and is particularly a favorite of casual users. The reason for this is three- 
fold: 

1) Apple ' specificallv concentrated on making the user interface as simple as 
possible through 'the use of common visual symbols and association. 

2) The company applied an extremely good and technically sound graphics 
package to the system. 

3) Apple took the best ideas of other attempts at developing window 
management systems and applied them to their design. 

As such, the Apple Macintosh has come to be accepted as the "unofficial" standard for 

the methodology of window management systems [Ref. 6], and it's interface is the 

foundation of this prototype design. 

a. The Infrastructure of the Macintosh Interface 

The Macintosh has been described as a universe with its own set of laws, 

similar to the laws of physics, that describe the standard behavior of objects. These 

"laws" are consistent which has a direct impact on how an application, and this 

prototype, is designed. Thus, the application should be flat and user driven (i.e. 

modeless) as opposed to being tree-structured and menu-driven. This allows the user 

to focus on what the application does, instead of how it does it. [Ref. 7] 

This "modeless" environment allows the user to do anything that makes 

sense at any time. This means the user is in control of what is going on with the 

computer and the application. It also means, in general, that if the user performs an 

action that makes "sense" then the "laws of nature" are not violated and the user 

doesn't get penalized for doing something wrong. This is a very' desireable feature in 

an application and is the basis for the Macintosh User Interface Standard. [Ref. 8] 
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The Macintosh User Interface Standard has nine basic concepts: 

the user to 



• Applications 

• Documents 

• Views 

• Commands 

• The Finder's Desktop Metaphor 

• Windows 

• Selections 

• Editing Conventions 

• Fonts 



These enable the user to manipulate 
information. 

These contain information which the 
application manipulates. 

These present information. 

These alter the information in specific ways. 

This provides an image of what is in 
Macintosh's memory and is a working 
environment for the information manipulation 
carried out on the Macintosh. 

These divide a portion of the Macintosh screen 
for a portion of the view. 

These identifv those portions of the information 
that can be' affected bv certain subsequent 
commands. 



These govern 
selections. 



the manner of specifying 



These provide a basis for manipulating text 
appearance. 

The reader may gain a comprehensive understanding of the Macintosh User Interface 
Standard by reading Inside Macintosh. 

b. The Application of the Interface Standards 

These concepts result in the user being presented, on the screen, a variety 
of graphic objects which behave in expected ways and represent information which the 
user understands. The user will see at the top of the screen a menu bar containing 
classes of commands. At the user's fingertips is a mouse whose movements cause the 
movements of a cursor on the screen. The user can position the cursor over a menu 
title , press the mouse button down and, while pressing it down, "pull-down" a list of 
menu items. These cursor movements which "pull down" something are commonly 
referred to as dragging and have a direct correlation to "dragging" the mouse across a 
table or desktop. If the mouse button is released over any menu item , that item is 
selected as the command to be performed. The action of pressing and releasing the 
mouse button is also known as clicking. Sometimes these menu items are "dimmed" 
and cannot be chosen, indicating they cannot be performed at that time by the 
application. 

The user also sees a window which presents information such as a document 
or a message. The window may be "active" and have its objects manipulated. More 
than one window can be presented at a time but only one may be active. The window 
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presents a view of its contents but not all of its contents may be visible. If so, the user 
must scroll through the information to see it all. The user may move the cursor all 
around the window and click in the window causing something to happen which the 
user would expect to happen. When finished with the window, the user can click in the 
close box and the window disappears. As with all user actions, the user sees and 
identifies some object, performs some action with regards to the object, and gets an 
expected result. This process happens because of the use of a set of Macintosh 
operating system routines. 

These routines are divided by function and are commonly called managers. 
The various managers used in most applications reside in the operating system or the 
User Interface Toolbox. The operating system performs such basic tasks as input, 
output, memory' management, and interrupt handling. The user interface toolbox, a 



level above the operating system, helps implement the standard Macintosh user 

% 

interface. It is through the variety of managers that the prototype is developed. The 



managers, all logically named, perform basic tasks as defined by Inside Macintosh 
[Ref. 9]. They are: 

• Resource ' This manager performs operations on, and allows access to. 

various application resources such as menus, fonts, icons, 
windows, etc. 

• QuickDraw The heart of the Macintosh user interface, this manager 

performs all graphics operations includina drawing 
something on tlie screen very quickly. It interfaces with 
many of the other toolbox managers. 

• Font Manager This manager supports the use of the various character fonts 

when text is drawn by QuickDraw. 



• Event Manager The Event Manager monitors the user's actions and 

coordinates the actions of the other toolbox routines. 



• Window Manager This manager controls the creation, manipulation and 

disposal of windows. 

• Control Manager The Control Manager handles special objects on the screen 

with which the user, using the mouse, can cause instant 
action with graphic results" or change settings to modify a 
future actionf 



• Menu Manager This manager creates sets of menus and allows the user to 

choose from the commands in those menus. 



• Text Edit This manager handles the basic text formatting and editing 

capabilities'Tn an application. 

• Dialog Manager This manager allows for implementing dialog boxes and the 

alert mechanism, two means of communication between the 
application and the end user. 

• Desk Manager The Desk Manager supports the use of desk accessories 

(mini-applications) in an application. 
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• Scrap Manager 

• Toolbox Utilities 

• Memory Manager 

• File Manager 

• Device Manager 



This manager supports cutting and pasting among 
applications and desk accessories. 

These are a set of routines and data tvpes that perform 
generallv useful operations such as fixed-point arithmetic, 
string manipulation, and logical operations on bits. 

This manager dynamically allocates and releases memory for 
use by the application and other parts of the operating 
system. 

The File Manager handles file input and output for the 
operating system! 

The Device Manager manages the input and output devices 
for the operating system. 

2. The Correlation of the MIP and the Macintosh User Interface. 

The design of any application must consider the operating system to be used 
as well as meeting the user's needs. The Macintosh operating system supports the use 
of high-level programming languages, primarily Pascal. One particularly fast and 
efficient version of Pascal is Turbo Pascal© by Borland, Inc. Turbo Pascal was this 
author's choice as the high-level programming language to use for testing some of the 
concepts of design used in developing this prototype. Turbo Pascal was deemed 
capable of meeting all requirements of the MIP in terms of functionability. 
a. The Restructured Data Flow Diagram 

A goal of any application design should be to provide for the smooth flow 
of data. Figure 2.3 identified a bottleneck of data flow. A distinct advantage of using 
the visual interface is that this bottleneck can be effectively removed while still leaving 
the "flow of control" with the user. Figure 3.1 depicts the changes of data flow. The 
player initiates the flow of data and subsequently controls it all, yet provides little or 
no data input. The primary' difference between this diagram and the first one is that 
this design use the stored information available to it, primarily the Player Initialization 
File (PIF), to transform data rather than the player providing the data to be 
transformed. The application thus runs smoother, information-wise. 

A refinement to the data flow diagram explicitly shows how this is 
supported, Figure 3.2. The transformation prepare directive is broken down into three 
layers. Each transformation's refinement is contained within the dotted lines in Figure 
3.2. Note that for each layer the information inputs and outputs are the same 
respectively. The input to the transformation is the create command and the output is 
the completed directive. In layer two, the transformation is broken down into three 
transformations which are get the directive type, get the directive attributes and assign 
attribute values. All the information needed is retrieved from stored information. The 
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Unit, Aircraft, Target, 




— Command 




Figure 3.1 The Restructured Data Flow Diagram. 




Directive 



Figure 3.2 The Refined Data Flow Diagram. 
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attribute information is wholly acquired from the P1F. In layer three, refinement of 
the transformation entitled assign attribute values results in the transformations find 
ranges/ choices available and assign choice to attribute. In following the data flow, the 
data always exists in the flow pattern and the player controls the data by selecting a 
choice. The player inputs the create command, is presented a list of directives, and 
selects one. That directive's attributes are presented, and for each attribute the player 
is presented a range or choice of values from the PIF and selects one to assign as the 
attribute's value. When all attributes have been assigned values (as required) the 
directive is complete. It is in this refinement that the MIP becomes an application of 
the visual interface. 

b. The Conversion of SIMSCRIPT to Pascal 

(1) The Data Structures. The source code of the MIP is lengthy and 
contains a large number of data structures of the type mentioned earlier in this thesis. 
There appears to be a strong correlation of these data structures to Pascal data 
structures. A SIMSCRIPT set is equivalent to a Pascal linked list. An entity is 
equivalent to a record or an array , dependent upon the particular entity. In most 
cases, an entity is of multiple data types so a record is an appropriate structure. An 
attribute is equivalent to a pointer or a variable of various types (real, double extended, 
integer, character, enumerated, subrange), or possibly even an array or record. 
Temporary entities are dynamically created during the course of the execution of the 
MIP, thus they would be created in Pascal as an addition to a linked list. Permanent 
entities exist throughout the course of the execution. These are created during 
initialization and their size is known. To correlate this to Pascal, the entities would be 
subscripted variables of an array of records since the size would be the dimension of the 
array. While SIMSCRIPT automatically provides some pointers and flags to indicate 
membership in a set or ownership of an entity, these would have to be declared as 
fields of a Pascal record. 

An example of this correlation is shown in Figure 3.3. In 
SIMSCRIPT, the AWACS directive needed all the entities shown in the figure as 
records. The Pascal version shows the linked lists, the records, and the data fields 
needed to create the AWACS directive. This correlation can generally be assigned 
across the board for all the MIP data structures used by the visual interface. 

It must be noted that all the data structures used for VAX terminal 
graphics and for alert, error messages are not needed for the visual interface 
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Figure 3.3 The AWACS Directive PASCAL Data Structures. 

application. The data contained in these structures is necessary due to the operating 
system used. The data structures necessary for the Macintosh operating system are 
inherent to it or can be explicitly addressed in the code or resource files. Specifically, 
the entities are interval _ , dat abase interrupt _, input _word, element _, command jconte.xt, 
recognized jeommand, CEP _parameter Jmdex , long_\vord, menu_line, and heldjdirective. 
There arc also several variables not needed which generally pertain to terminal 
graphics. Should any question arise about the purpose of and necessity for any 
SIMSCRIPT d.ata structures to be used in the visual interface, the reader should refer 
to the source code and the M1P Software Engineering Maintenance Manual, Reference 
10 . 

(2) The Source Code. SIMSCRIPT II. 5© was designed to support 
structured programming and modularity as applications ' of software engineering 
[Ref. 1: p. i]. As such, many of the coding conventions of the SIMSCRIPT language 
are similar to the language constructs of the high-level programming languages such as 
Pascal. The if-then-ehe, do-while , and case statements are examples of condition 
statements common to both languages. 

Reserve , define , mode , and dimension arc typical assignment statements 
in SIMSCRIPT, but must be handled through Pascal declaration and assignment 
statements accordingly. The use of boolean arguments is common to both languages 
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and the operators are the same. A brief review of the SIMSCRIPT reference would 
allow any programmer with just moderate Pascal experience the ability to read and 
follow the source code. 

c. The Prototype of the MIP Functions 

(1) The Commands. The commands have a direct functional correlation 
to menu items in the Macintosh environment. The commands can be grouped by class 
in nearly all cases. The classes of commands are implemented as menu titles. The few 
which are not associated closely with a particular class have been loosely grouped 
together into a class entitled special. In one case, a single command w r as categorized as 
a class itself. This w r as the find command. Several commands are also inherent to the 
Macintosh operating system. An example of this is the hold command. It is equivalent 
to the Macintosh open command. 

The specific menu items and their functional definitions are as follow's: 

• About... About... prompts the display of a window' containing 

information about this prototype. 



• DeskAccessory 

• Create 

• Open 

• Save 

• Save as... 

• Close 

• Print 

• Send 

• Verify 

• Quit 

• Group Create 

• Leave 

• Join 

• Group Send 

• Time Increment 



This command calls the specified desk accessory to begin 
operation (normally on-screen) for the user. 

This calls a procedure to create an action or utility directive. 

Open , an operating system feature, is similar to the MIP's 
hold command; it opens an existing file or document. 

This operating system feature stores a named file. 

This operating svstem feature stores a file after prompting for 
and receiving a filename from the user. 

This operating svstem feature closes ah open file. The user is 
given a choice, if necessary, of saving changes or not. 

This operating system feature prints the open file at the 
Macintosh printer. 

Send calls the send procedure to send a directive to the game. 

This command calls the verify procedure to ensure a directive 
is OK to send to the game. 

This operating svstem feature quits executing the application 
when selectedf 

This command calls a procedure to create a group of 
directives. 

This command calls a procedure to take a directive out of a 
group. 

This command adds a directive to a group. 

This command sends a group of directives to the game. 

This command calls the IncGroupTime procedure to 
increment the execution time of the groups directives bv a 
certain amount. 
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• Transmit Message This command allows a player to prepare and send a message 

to another player or a group of players. 



• Receive Message 

• Query 

• Graphics 

• Find 

• Edit 

• 'Trash' 



This command allows a player to read his messages which are 
in the message queue. 

The query command lets the player request a report from the 
game. 

This command permits the player to make adjustments to his- 
graphics station during the course of the game. 

This is a class of commands to find a specific group, directive, 
message or report which the player may have filed away. 

This class of commands is composed entirelv of operating 
system commands which the player uses to edit'text. etc. 

This command permits the deletion of anv file bv "dragging" 
that item to the trash can so the can is highlighted - . 

These commands are incorporated into the Macintosh application by 
pre-coding them into a resource file. The resource file is read by the application 
program and the menu bar is constructed from the data contained there. Subsequently, 
any time a menu item is selected by a player, the command is carried out by the 
program. An interesting feature of the menu items (and an entire menu list), is that 
they can be enabled or disabled as required during the course of execution of the 
program. Certain V1IP commands cannot be performed while other actions are being 
performed by the player. The Macintosh program can handle these situations by 
disabling the necessary commands in the menus. 

The maintenance of the menu items must be done in three places, 
dependent upon the maintenance required. The resource file must be updated, the 
menu resource declaration in the program may need to be updated, and the source 
code to handle the menu event must reflect the changes made, as required. While this 
maintenance, on paper, seems elaborate, in practice it is relatively simple in most cases 
and will probably be rare as the addition or deletion of commands is not anticipated 
for the game itself. The source code may change as procedures called from the 
commands are added or deleted. 

(2) The Directives. The directives correlation to the prototype is that they 
represent information to be manipulated. Manipulation of information is done via the 
window. Hence, each directive is displayed in a window. The directive attributes are 
displayed as information with predefined positions in the window. It is possible (and 
very probable) that they will not all be visible to the player. The player will have to 
scroll to view the attributes remaining out of view. 
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The method of assigning values to an attribute is consistent and 
straight forward. The player moves the cursor over an attribute and clicks the mouse 
button. This event activates a procedure which draws a dialog window. The contents of 
the dialog window are dependent upon the range or choice of values which can be 
assigned to that attribute as it's value. Controls are used to make the assignments. If a 
number is needed, a control called a dial control is used with minimum and maximum 
values representing the range of values for that attribute. If a string is needed, such as 
a choice from a list, the list is displayed and each item has it's own button control. The 
player selects the choice and that choice is assigned as the attribute value. 

The attribute values all represent some data base information stored in 
the individual player's functional game file called the Player Initialization File (PIF). 
The PIF gets created by the game director during game preparation and represents the 
only correct and authorized set of information in any given game scenario. Bv using 
the PIF, the range, choice of values can be determined ' based on the conditions of 
directive type, units and their missions, unit resources, resource characteristics, and 
environmental data. It should be stressed that direct usage of the PIF data to populate 
"pop-up" windows or dialog windows is very efficient and not now being done in the 
current version. By reading the given PIF data into the dialog window, a value can be 
selected by the player. This is a significant change since the player no longer has to 
thumb through a sometimes large "player manual" to choose data and then correctly 
enter that data via the keyboard. The player can see that data in front of him. 
comprehend it quickly, and "enter" the data in syntactically correct format; all by 
clicking a button! 

This process is repeated many times during the course of a game and is 
in keeping with the refined data flow diagram design. Figure 3.2. It is natural, 
consistent, and permissive (for the most part) - three fundamentals in designing a visual 
interface such as this prototype for the Macintosh [Ref. 9: p. 1-27]. In the following 
sections, the prototype is established as an application and the reader will be able to 
see how the aforementioned processes are implemented in an application such as the 
MIP. 
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B. THE PROTOTYPE - MACMIP 
1. The Prototype Abstraction 

The prototype, appropriately named MacMIP, was developed to provide the 
JCS managers another way to use and play JTLS. This prototype takes on a different 
appearance than most programs. Macintosh documentation stresses the point that 
Macintosh programs like MacMIP "don't quite look the way they do on other 
systems." In Apple's words, "Everything you know is wrong." [Ref. 9: pp. 1-4, 
4( Draft)] 

The reason is simply that event-driven programs behave differently and have a 
different structure. The first-level abstraction of MacMIP, Figure 3.4, shows the set-up 
of the program. 



Program MacMIP (Input, Output); 

Declarations 

Libraries; 

Constants; 

Types; 

Variables; 

Utility Functions and Procedures; 

Menu Driven Functions and Procedures; 
Event Driven Functions and Procedures; 
Initialization Functions and Procedures; 
Cleanup Functions and Procedures; 

Main Program. 



Figure 3.4 An Overview of MacMIP's Program Structure. 

In the material that follows, the first-level abstraction is refined into an 
abstraction level that is suitable for use as a guide for coding the prototype. The 
refined abstraction is a third-level abstraction and it's elements are categorized and 
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their purpose defined. In fact, the third-level abstraction was used to code the 
prototype version used in the code comparison section of Chapter 2. The results of 
that code comparison demonstrate the desirability of continuing with the development 
of the prototype from an efficiency standpoint. A complete version of the third-level 
abstraction may be found in appendix A of this thesis. 
a. The Header and Declarations 



The header is typical of any program. It simply invokes the program. The 
declarations section is again typical. It identifies operating system libraries used, 
establishes global variables by type, assigns values to constants (including the 
identification of resource files used), and formally sets up the data structures. 

The first significant difference from most programs is in the declaration of 
procedures. These application-specific procedures are categorically grouped together. 
The categories are utility , menu-driven , event-handling , initialization, and cleanup. 



(1) Utility Functions and Procedures. The utility category is generally used 
as a catchall for the functions and procedures which do not belong to any other 



category. The utility functions and procedures and their purposes are as follows: 

• Directive This procedure draws a specific directive onto the 

screen. It is called when a directive tvpe has been 
specified. 

• Attribute Display This procedure highlights a directive attribute, 

calls a dialog box and displavs the attributes 
range choice of values for selection, returns the 
selected value, and assigns it to the attribute. It is 
activated by an event. 



• Assignments This is a set of procedures which match up to 

directive types. They handle anomalies in the 
process of assigning 'directive attribute values to 
particular fields of player orders. These are 
necessary since the MlP'does not have a generic 
algorithm to do this. 

• Verify This is also a set of procedures which match up to 

directive types. Each verifies that the specific 
directive attributes are correct (outside of standard 
tvpe-checking) and are assigned to the appropriate 
held in the directive record." They are called bv the 
Send, Verify, Group Send, and Group Verify 
command procedures. 

• Retrieve Attribute Values This simplv assigns attribute values to specific 

directive fields. 



• Player Order Assignment This procedure creates a plaver order record bv 

assigning a directive's attribute values into specific 
plaver order fields in order to "match up" to the 
CEP's equivalent of a player order record. To 
handle the anomalies of any specific directive, the 
procedure calls the necessarv assignment 
procedure. Plaver Order Assignment is called bv 
the Send. Group Send. Querv, and Transmit 
Message commands procedures. 
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• Mail a Player Order/Message This concatenates the player order or message into 

a string for purposes ot sending it as an ASCII file 
to the CEP. It is called'' by Player Order 
Assignment. 



• Quick Order Display 

• Quick Attribute Display 

• List Control 

• Time Dial Control 

• Lat/Long Dial Control 

• Integer Dial Control 

• Real Dial Control 

• .Lat/Long Conversion 



This procedure behaves similarly to Directive 
Displav. It is called bv the Query’ and Graphics 
Adjust' command procedures. 

This behaves similarly to Attribute Display. 

This procedure takes a list, assigns each list 
member a control, and then draws the control into 
a dialog box. It is called by numerous procedures. 

This procedure creates a dial control with range 
values commensurate with a minimum and 
maximum time, and draws the control into a 
dialog box. It returns a time value. 

This procedure creates a dial control, with 

minimum and maximum values, and draws it into 
a dialog box. It returns a latitude, longitude point. 

This procedure creates a dial control, with 

minimum and maximum values, and draws it into 
a dialog box. It returns an integer value. 

This procedure creates a dial control, with 

minimum and maximum values, and draws it into 
a dialog box. It returns a real value. 

This function takes the starting geographic 
point(SW) and the number of x.y hexes and 
determines the NE point of the plaving surface. It 
then converts that point to lat, long' coordinates for 
use as game boundaries. 



• Read From VAX 

• Write To VAX 

• PIF Update 

• Write The Status 

• Write the Player 



This procedure is used to communicate with the 
VAX dv receiving. 

This procedure is used to communicate to the 
VAX by writing to it. 

This is used to update a wide variety of the 
plaver's database when MacMip 'is used 
interactively during game play. 

This procedure writes and updates that status 
dialog window. It is called by PIF Update. 

This procedure writes and updates the plaver 
dialog window. It is called primarily during 
initialization. 



• CRR Get This is a set of procedures which get lists, times. 

geographic points, altitudes, etc. Each procedure 
Has "3 direct correlation to the MIP source code. 
They are called by numerous higher-level 
procedures. 

(2) Menu-Driven Functions and Procedures. The menu-driven category is a 



collection of functions and procedures which are called as a result of a player selecting 
a menu item. These functions and procedures may in turn call a host of utility and 



57 



operating system functions and procedures. In general, these are called only from the 
Handle Menu procedure in response to an event. They are essentially used to carry out 
MIP commands which are not handled by the operating system. The menu-driven 



functions and procedures are: 



• Do 



This procedure simplv draws a dialog box whose contents 
are information abou't MacMIP. It calls nothing. 



• Desk Accessory 



This procedure starts up a specified desk accessory for the 
player's use. 



• Create 



• Send 



• Verify 



This procedure issues . the command to create a new 
directive. It calls a dialog window so the plaver mav 
select a directive type. When the tvpe is chosen, the 
Directive Display procedure is called. 

This procedure prepares actions directives for "mailing" 
and then places the orders into the mailboxes. It calls 
Verify, Player Order, and Mail a Player Order/Message. 

This procedure calls a directive specific verify procedure. 



• Group Create 



This procedure establishes a group into which directives 
may be collected. 



• Join 



This procedure assigns an existing directive to a group. 



• Leave 



This procedure removes a specific directive from a group. 



• Group Send This . procedure prepares a group of directives for 

"mailing" to the CEP and then places them in the 
mailbox. . It calls the Verify and Send procedures for each 
directive in the group. 



• Group Verify This procedure verifies that each directive in a group can 

be sent to the game. It calls the Verify procedure for 
each directive in "the group. 

• Group Time Increment This procedure increments the time of execution for each 

directive in a group. It calls the CRR Get and the Time 
Dial Control procedures. 



• Transmit Message This procedure allows the plaver to create and send a text 

message to another plaver or'plavers. It calls the Mail a 
Playef'Order; Message procedure. ' 



• Receive Message This procedure retrieves a message from the player's 

message queue and displays it on the screen so the player 
may view it. 



• Query 



• Graphics Adjust 



• Find 



This procedure, similar to Create, requests reports from 
the game when MacMIP is in the interactive mode of 
operation. It calls the Quick Order Display procedure. 

This procedure, also similar to Create, makes adjustments 
to the player's game graphics stations. It calls the Quick 
Order Display procedure. 

These procedures find anv particular group, action 
directive, utility directive, riiessage, or report that the 
player has filed away. 
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(3) Event-Driven Functions and Procedures. The event-driven procedures 
are those procedures which are performed as the result of the occurrence of some 
event. An event is normally a mouse click or a keystroke performed by the player. 
System events, such as the movement of the mouse, are also members of this category. 
Parameters of the events are examined to determine what occurred, where it occurred, 
and what is supposed to happen next. In turn, the event-driven procedures are 
invoked to handle the event. In a sense, these procedures are the "brains and nerve 
center" behind the application's "bodily functions." The procedures are: 

• Mouse This procedure identifies where the mouse was clicked and then 

calls another event to handle the task to be done as a result of the 
click and it's location. 

• Keypress This procedure handles a keystroke event, including command 

keys. It may or may not explicitly call other event procedures. 

• Update This procedure handles updates to the three windows of MacMIP. 

It calls various procedures dependent upon w’hat needs to be • 
updated. 

• Handle Menu This procedure handles the event of a click in a menu item and 

calls the necessarv menu-driven procedure including operating 
system procedures.' 

• Cursor Adjust This procedure changes cursors based upon the cursor's screen 

position as a result ofmouse movement. 

• Handle Event This procedure determines what event occurred and oversees the 

performance of the task to be done as a result of the event. 

(4) Initialization and Cleanup Procedures. The Initialization and cleanup 
procedures are the start and stop of the program. The .initialization procedure 
initializes everything in the program at the start of the program's execution. It could 
be constructed as a combination of several procedures but here.it has been treated as a 
single giant procedure with calls to a few utility procedures. The cleanup procedure is 
invoked at the termination of the game. It simply erases the contents of the screen, 
logs off the VAX, and shuts down the Macintosh. The initialization and cleanup 
procedures are each invoked once during the execution of MacMIP. 

b. The Main Body of MacMIP 

The main body of MacMIP is a short, concise set of statements which are 
the "soul" of the Macintosh. After initialization, the program performs a repeating 
loop until told to quit. The loop first checks to see if any systems-defined tasks need 
to be done. If so, the Macintosh does them. The loop then checks to see if any events 
are in the event queue. If so, the system gets the first event of the highest priority 
class and performs the event-driven task. It then repeats the loop. When the system is 
told to quit, it invokes Cleanup and erases the screen. 
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2. Background Issues of Prototype Design 

There were several issues which were (and still are) challenges to fully implementing 
MacMIP. The challenges primarily of interest here are the transition of an application 
(the MIP) from one computer system to another of a different format and the physical 
data link between the different systems. These challenges are not impassible but they 
do warrant special mention so the reader understands the task at hand. 

The task of implementing a prompt-based program, designed and written for a 
VAX minicomputer, into a graphics-oriented, event-driven operating system such as 
the Macintosh provides several challenges. First, it is not a trivial process since the 
Macintosh applications do not carry’ out a sequence of steps in a predetermined order. 
Rather, the Macintosh program is driven by user actions (such as clicking and typing) 
whose order of occurrence cannot be predicted. Thus, the SIM SCRIPT program 
cannot be running parallel to the Macintosh and expect the Macintosh to emulate a 
VAX terminal and still function in the visual interface mode. Mac VI IP must be 
programmed to account for the occurrence of events; the VHP’s prompt-based 
applications are not event-driven. 

Secondly, a thorough concept of graphics capabilities is necessary to 
effectively apply the visual interface to the VHP through the Vlacintosh operating 
system. Prompt-based applications such as the VHP generally use "menus" to display 
the prompts. Moving through the prompts is done sequentially due to the 
application's rigid tree-like hierarchical structure; one prompt must be answered 
correctly before another one can be dealt with, especially if it resides on another level 
of the hierarchy. The code to set-up the prompts and move between them is usually 
rigidly structured as well. The Macintosh system does all this through the use of it's 
graphics toolbox QuickDraw and the Resource Manager. Thus, any MIP source code 
dealing with the CRT display is totally unusable in MacMIP. To try to transfer it to 
the Vlacintosh would require too much source code just to negate those CRT 
instructions. Simply stated, reformatting is not trivial. 

The other issue of establishing a link to the VAX is also one which is possible 
but not trivial. Although the exact mechanics of establishing the link will not be dealt 
with here, it must be noted that the capability to link the Vlacintosh to the VAX has 
been demonstrated by the Jet Propulsion Laboratory, the Naval Postgraduate School's 
C3 Laboratory’, and the Warrior Preparation Center, among others. The reason for 
mentioning it is that the Vlacintosh runs only one application at a time. Therefore, the 
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instructions to link to the VAX on an interactive basis must be incorporated into 
MacMIP's source code. It is also likely that the JTLS Executive Level Program must 
know that a particular link and game mailbox is a Macintosh and not a VAX VT-100 
terminal. With these issues in mind, the general format and design of the prototype 
can be implemented. 

C. CREATING DIRECTIVES WITH MACMIP 

The use of MacMIP to create the AWACS directive will result in the same 
directive being created as examined earlier in this thesis. The method of creating it 
now has a new look. To appreciate this prototype, the reader is invited to step 
through the process again. 

The process begins with the player. With the mouse at his fingertips, the player 
moves the cursor around on the screen. As the cursor moves across the menu bar. the 
player positions the cursor over one of the menu titles and presses the mouse button. 
While holding down the mouse button, the player "pulls down" a list of menu items by 
dragging the mouse, Figure 3.5. As the cursor passes over the pulled-down menu 
items, the player releases the mouse button while the cursor is positioned over the 
create command. This constitutes an event so the Macintosh software determines what 
event occurred and where, and, having recognized the event, handles it. In doing so, 
the menu-driven procedure Create is invoked. 

The issuance of a command starts the ball rolling. First, MacMip reads a 
resource file to get a dialog window, gets a list of directives the player can create, 
invokes list control, and finally draws all of them onto the screen, Figure 3.6. The 
player can quickly and easily see what his options are. The player can select a specific 
directive type or cancel the create and quit. If the player cancels, nothing happens 
except the command is canceled. Actually, the player can quit at any time without 
penalty; the main window is simply erased. If the player selects a directive type such as 
AWACS, Directive Display is invoked. 

When Directive Display is invoked, MacMIP reads a resource file which places 
control buttons in a pre-determined order, assigns an attribute name to each button, 
and draws the AWACS attributes onto the contents region of the main window. As 
the player clicks on any attribute, the attribute control is enabled and invokes the 
attribute display procedure. 
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Figure 3.5 The MacMIP Menu Bar with Menu Items. 

Now MacMIP determines the type of attributes (squadron, for example) clicked 
on and determines the range of values or choices eligible to be assigned as the 
attribute’s value. .In the case of squadron, this would be a list of air squadrons with an 
AWACS mission. MacMIP then draws a dialog box, with the appropriate controls 
and information, Figure 3.7, and waits for the user to select a value. Once this is done, 
MacMIP assigns the value to the attribute. For example, 73 AWACS SQ would be 
selected as the value of the attribute squadron. The dialog box is erased and the 
portion of the directive covered by the dialog box is redrawn. 

When the player selects an attribute which is a utility directive, such as Air 
Route, the player has the option of referencing the air route ID or creating the air 
route directive. If the first option is selected, MacMIP behaves as normally expected 
for an attribute and displays a list of choices. One choice is an empty textedit box so 
the player can reference a yet to be created Air Route. If the player chooses the latter 
option, MacMIP remembers the AWACS window, invokes Directive Display again, 
given a type of "air route", and draws a new window over the AWACS window. 
NOTE: This is similar to the OVERMIP feature of the MIP but this is not restricted 
to just three windows or limited performance of commands. With a new window. 
MacMIP can perform any command allowed for an active window and it’s function, 
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Figure 3.6 The AWACS Directive as drawn by MacMIP. 

regardless of the number of windows. Practical limitations of approximately 12 
window's are dictated by Macintosh operating software but the only physical limitation 
is with memory space on the system. Now Air Route is handled just like any other 
directive. When the player is done with Air Route, he simply saves it. The Air Route 
window is erased while it's information is stored somewhere in memory, 'file player is 
now returned to the AWACS directive window’ and continues to process information in 
it. 

This process continues on for the player at his will, lie would never have to hold 
a printout on his lap to find data. It would always be available to him on his 
computer "desktop." The player would control the data yet quickly move between 
different tasks of varying modes as he deemed necessary and never lose any 
"document." It would always be somewhere on his desktop! 
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F igure 3.7 The Directive with the Dialog Box. 



D. THE FUTURE UTILIZATION OF THE PROTOTYPE 
1. Technical Aspects of Prototype Utilization 

A brief review of the methodology used is in order to shape the prototype's 
future. The methodology used to develop this prototype was simple and 
straightforward. The ultimate goal was established as the application of the Model 
Interface Program onto the Macintosh operating system. The process of doing this 
can be mapped out in steps. First, understand the MIP operations, i.e. what it does. 
Then understand the S1MSCRIPT program language and how it operates on the VAX 
minicomputer. A collateral task is to understand the Macintosh operating system, it's 
capabilities, and the programs it uses well. Then the task is to understand the design 
and structure of the MIP and correlate it into a design using the visual interface. Once 
this is done, the next phase is to translate the design concepts into a code-like format 
so the prototype takes on a realistic look. This is the point where the prototype 
development is now. 
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In getting the prototype to this point, much of the original source code was 
examined to determine how the MIP works. In doing so, it became evident that much 
of the logic and algorithms used would be effective in MacMIP. The reason is that the 
"behind the screen" manipulation of information by the MIP is fairly effective so there 
is no reason to re-invent the wheel. It is the format and presentation of the data which 
sparked the idea for the prototype in the first place. With this in mind, it becomes self- 
serving to use that code in this prototype. This is evident by the references made to 
specific MIP modules in the MacMIP psuedocode. An underlying premise is that the 
development and production of MacMIP would be considerably shortened compared 
to a full re-design. 

There were numerous ideas borne out of this development with regards to 
future prototype development. One idea mentioned earlier was that of placing 
individual directives into resource files. This would speed-up Macintosh operations 
and provide a cleaner, sleeker display. The better the graphics, the better the visual 
interface. The MIP currently reads in all commands and all of the various directives, 
queries, adjustments, etc., from a database. The database is not expected to change 
significantly over time so maintenance and currency should not be significantly 
impacted upon. While the MIP currently reads the data in based upon player function, 
the same school of thought could apply to MacMIP. The answer is to have a separate 
diskette per function and simply load that function's diskette into the Macintosh when 
that function is used. One advantage to this is to effectively utilize memory space. 
Another advantage, for game management, will be addressed shortly. 

A second idea, which follows the lead of the first, is to place each player's PIF 
on a separate diskette as well. The PIF is developed by the CEP upon initialization of 
a scenario database. Since the PIF doesn't change unless the scenario does, it is 
feasible to pre-load the PIF for each scenario used. A separate diskette per function 
per scenario would allow great flexibility in the use of the prototype. An extension of 
this advantage would be that only the function affected by a change to a scenario 
would have to be updated. This idea would also save machine memory space, a 
concept which closely relates to the way JTLS already reduces CPU input output by 
using video disc digital graphics. 

Another feature of the MIP which has not been addressed in the prototype is 
the system capability for the expert player. Presently the expert player can type all the 
directive data into one string in a predetermined order (this is called stacking), enter it, 
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and have a complete directive. This capability is a natural for a prompt-based 
application. However, with the Macintosh and the visual interface format in use, the 
stacking capability is a diametrical opposite. As such, it was not designed into the 
prototype. To fully realize the potential of MacMIP, this capability should be 
incorporated into MacMIP as a text edit faculty. 

Finally, an aspect of development to be considered is a total re-design of the 
MIP. The key issue with the MIP is it's ability to communicate the player's intentions 
to the game. This is done by passing ASCII data between the two programs. 
Therefore, the MIP could manipulate it's data in many different ways just as long as 
the file passed was in proper order and format. Consider first that SIMSCRIPT is a 
modeling programming language. The MIP per se models nothing. It is written in 
SIMSCRIPT to be consistent with the other JTLS programs. Instead of being a model 
which generates data, the MIP simply manipulates data. Since the MIP manipulates 
data, consider the possibility that there is a more efficient method of manipulating that 
data. That method is a data base management system (DBMS). Several excellent 
systems exist which were designed expressly for the Macintosh. One of these or a 
specially designed system might do a better job of dynamically manipulating the large 
amounts of data used in JTLS. If a decision w r as made to use a very capable 
workstation, such as the SUN or IRIS workstations, for a future generation JTLS 
input device, a DBMS system coupled with a windowing and resident color graphics 
environment becomes a very attractive system option. A single workstation could 
easily function as a graphics station and MIP substitute. 

2. Managerial Aspects of Prototype Utilization 

JTLS was originally developed with military training in mind. As events have 
transpired that original premise has been overcome. The issue of computer simulations 
used as planning aids has come to the forefront. With the proliferation of the desktop 
microcomputer, prototypes like MacMIP take on increased importance. One 
important reason is found in the methods used by planners to test various strategies 
and tactics. A planner develops a strategy and then must test it for feasibility. If the 
planner could prepare in advance all of the missions expected to be used for a given 
strategy, then the planner could do all that work in his office where all his references, 
working papers, etc., are located. When the planner tests his plan, it is done in the 
computer laboratory. Using a portable system of diskettes from a desktop computer, 
the directives could be transported (so could the Macintosh for that matter) to the lab 
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and loaded into the game. This would save a considerable amount of time for the 
planner as the game could be played faster, more repetitions could be run with more 
variations of game parameters, and a greater spectrum of outcomes realized for 
analysis of plan effectiveness. 

A reason of secondary importance is found in the basic premise of the visual 
interface. It is geared toward the casual user. The military planner is not a computer 
systems expert by trade. The planner's expertise can range from the novice category to 
the expert. By designing and using a system like the Macintosh, with it's visual 
interface, the needs of all users can be met. One can assume that even the expert is 
not likely to use JTLS on an everyday basis over an extended period of time. With so 
much diversity in . a planner's work, it would be easy for even the expert JTLS 
gamesman to lose his grasp of the game's nuances. With a continual change of 
scenarios, the data used by the player would change and further compound the 
problem of maintaining game skills. The prototype would quickly return the planner 
to a high level of effectiveness in game skills, or quickly train the planner new to JTLS, 
due to it's graphical orientation and it's ease of use. If correctly designed it will also 
reduce input error rates at all stages of training of the player-analyst or player-planner. 
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IV. CONCLUSIONS 



The original purpose of this thesis was to examine enhancement of player inputs 
to JTLS through computer graphics techniques. The overall result of the examination 
is that a graphical application of the game is a very efficient and a desirable method to 
effect player inputs. This result is supported by positive use of human visual 
information transfer, the ability of computer software such as window management 
systems to convey this information, and the capabilities of hardware such as the 
Macintosh operating system. Symbolic association has long been recognized as a 
positive method of communication. The use of computer graphics is a logical 
extension of that school of thought and has found an application in window 
management systems. The windowing capabilities in the Macintosh, when compared 
to the prompt-based VAX. show a distinct advantage in providing ease of player input 
and, at the same time, indicates a potential savings in the amount of code necessary to 
perform- the same operations on the VAX. The results of this examination fully 
supported the development of the prototype. 

The prototype design shows how to improve the current methods of effecting 
player inputs. The design of the prototype incorporates the advantages mentioned 
above. The design identifies the areas of the Model Interface Program most in need of 
enhancement and then breaks down the functions of each area by correlating them into 
visual (graphical) objects. The design also identifies a very capable language (Pascal) 
for coding such a prototype and correlates the original SIMSCRIPT source code (data 
structures, logic, and language constructs) to it. 

This road map of design leads directly to the pseudocode abstractions. These 
abstractions show that the coding of the prototype is possible and goes so far as to lay 
out the program's skeletal structure. The categorization of MIP functions allows for 
explicit definitions and routines of MacMIP which in turn perform the MI P's 
functions. The road map allows for a total rewrite of the MIP. The next step to be 
taken in the design process is to actually begin coding. Although a total rewrite is a 
large undertaking, and beyond the scope of this thesis, it is the most efficient and 
economical method of implementing the graphical enhancements. 
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In the case of the Macintosh, the powerful capabilities of the microcomputer 
would be lost if it was coded to simply emulate a VAX VT-100 terminal. Then the 
Macintosh graphics would not provide any true enhancements to the player input 
mechanism. Also, while the psuedocode was written with the Macintosh in mind, it is 
purported to be general enough to provide decisionmakers a basis for which to apply 
the MIP functions to other graphics-oriented window management computer 
workstations. Indeed, the proliferation of low-cost microcomputers with graphics 
capabilities give the prototype increased credibility. 

In summary, the prototype can be a valuable tool to JTLS managers in the near 
future. The design is generic enough to apply to any window management system but 
is ready to be coded for the Macintosh. The best of the original source code has been 
applied to the prototype to aid quick implementation. It's use in a desktop, office 
environment will provide the manager greater flexibility in utilizing JTLS to it's full 
capability and worth. 
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APPENDIX 

MACMIP: THIRD-LEVEL ABSTRACTION 



**************************************** HEADER **************************************** 
P rogram MacMI P ( I npu t , Ou tpu t ) 

************ * ** ** ************ DECLARATIONS (of the globals) **************************** 
*** Operating System Functions *** 



($R± ) 

($I± ) 

( $1 <filename>) 
( $B± ) 


* range checking, on/off 
* input/output error checking, on/off 
inclusion of file(s) 

*bundle bit, on/off 



( $R <f ilename>. Rsrc ) identify resource files used 



<$T APPLDM01 ) 
( $U± ) 

( $S± ) 


*set application identification 
*auto-link to runtime units, on/off 
*use of segmented code, on/off 



( $S <segment name>) *name of segmented code used 

*** Macintosh Interface Units *** 



USES 

PasInOut 


implements the standard Pascal input/output (I/O) routines. 


MemTypes 


*Defines special Macintosh data types and must be in any Mac-style 
application. 


J QuickDraw 


♦ 

*The Macintosh graphics package. 


SCSIIntf 


*Provides access to interface port and permits communications with 
the port. 


OSIntf 


*The operating systems interface which performs lowest level basic 
tasks . 


Toolntf 


implements the user interface features of windows, menus, 
controls, dialog boxes, text editing commands, etc., and must be 
in any Mac-style application. 


Packlntf 


*The interface to packages of data structures and routines which 
are stored as resources. 


MacPrint 


*Provides access to Macintosh printing manager. 



( ** NOT USED: Any of the following may actually be needed when MacMIP is actually coded, 
however, they do not appear necessary at this time: PasControl, PasPrinter, SANE, 
FixMath, Graf 3d, AppleTalk, Speechlntf . ** ) 

*************************** Constants, Types, and Variables *************************** 



CONSTANTS 

Menu List Count 
Apple Menu = xx 
File Menu =xx 
Group File Menu 
Edit Menu 


= 6 *total number of menus 

*the resource 
*ID unique 

=xx *to each 

*specif ic 



Special Menu = xx *menu file 



Find Menu =xx 
AM = x 


index 
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TYPE 



FM = x 
GM = x 
EM = x 
SM « x 
FDM = x 

Main Window ID = xxxx 
Status Window ID = xxxx 
Player Window ID = xxxx 
Attribute Window ID = xxxx 

Buffer Size = xxx 
Buffer Count = xxx 



*into 

*menu list 
*f or 
*each 
*menu 



*the re source ID 
^unique to each 
*specif ic 
*window used 

*for disk I/O 
*for disk I/O 



Player 


File = RECORD of 








PF 


Concat . F 


: char 






PF 


Suffix 


: char 






PF 


Unit 


: integer 




Player 


= RECORD of 










PL 


side 




char 




PL 


side number 


integer 




PL 


function 




char 




PL 


function 


no. 


integer 




PL 


rece ives 


input 


integer 




PL 


graphics 


station 


integer 


Ma i lbox 


= RECORD 


of 








MBX logical 


name : char 




MBX size 


: integer 




MBX channel 


: integer 



Message = RECORD of 



Unit = RECORD 



MSG status : integer 




MSG text : char 




of 




UT Pointer 


integer 


UT long name 


string 


UT short name 


string 


UT type 


integer 


UT AS aircraft available 


integer 


UT AS aircraft type 


integer 


UT side 


integer 



Directive = 



RECORD of 




DIR ID 


char 


DIR unit 1 


char 


DIR unit 2 


char 


DIR unit 3 


char 


DIR unit 4 


char 


DIR target 1 


char 


DIR target 2 


char 


DIR lat 1 


double 


DIR lat 1 text 


char 


DIR Ion 1 


double 


DIR Ion 1 text 


char 


DIR lat 2 


double 


DIR lat 2 text 


char 


DIR Ion 2 


double 


DIR Ion 2 text 


char 


DIR time 


double 


DIR time text 


char 


DIR duration 


double 


DIR duration text 


char 


DIR generic 1 text 


char 


DIR generic 2 text 


char 


DIR generic 3 text 


char 



extended 

extended 

extended 

extended 

extended 

extended 
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DIR 


generic 1 


integer 


integer 


DIR 


generic 2 


integer 


integer 


DIR 


generic 3 


integer 


integer 


DIR 


generic 4 


integer 


integer 


DIR 


generic 1 


double 


double extended 


DIR 


generic 2 


double 


double extended 


DIR 


generic 3 


double 


double extended 


DIR 


generic 4 


double 


double extended 


DIR 


generic 1 


Ipointer 


integer 


DIR 


generic 1 


Tpointer 


integer 


DIR 


generic 1 


Dpointer 


integer 


Attribute Prototype 


= RECORD 


of 




AP 


prompt 


: string 


AP 


field code 


: string 


AP 


arguments string : string 


AP 


number 


: integer 


Directive Prototype 


= RECORD 


of 




DP 


long name 




string 


DP 


short name 




: string 


DP 


meaning 


: 


integer 


DP 


CEP class 


• 


integer 


DP 


assignment 


routine 


integer 


DP 


verify routine 


integer 


DP 


attribute prototype 


array ( 1 to 12 ) of RECORD 


DP 


number attributes 


integer 


Quick Attribute Prototype = 1 


RECORD of 





QAP prompt : string 

QAP create routine : integer 

QAP arguments string : string 

QAP conversion type : integer 

QAP PO word : integer 

QAP all flag : integer 



Quick Order Prototype = RECORD 
QOP context 
QOP full name 
QOP numeric name 
QOP CEP class 
QOP CEP specific 
QOP CEP number 
QOP message 
QOPQAP 



of 

: integer 

string 
: string 

: integer 

type : integer 

: integer 

: integer 

: array (1 to 4) of RECORD 



Air Weapon 



Aircraf t 



= RECORD of 

AH name : string 

AW X air ground : real 

AW X weapon weight : real 

AW X supply category : real 

AW X night factor : real 

AW X weather factor : real 

AW X weapon color : real 

AW X weapon effects : real 

AW X long range : real 

AW X precision guided : real 

AW X weapon speed : real 

RECORD of 

AC name : string 

AC X range : real 

AC X day night : real 

AC X crew time : real 

AC X fuel : real 

AC X weather factor : real 

AC X runway required : real 

AC X type : real 

AC X wet weight : real 
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AC X dry weight : real 
AW X EC factor : real 
AC X max altitude : real 
AC X speed ; real 
AC X load time : real 
AC X aircraft side : real 
AC X damage ratio : real 
AC X refuel : real 
AC X spare : real 
AC X enemy detection : real 
AC X engage fuel : real 
AW X AI range : real 



Supply Side* Supply 
$S 
SS 

ss 



Category 

name 

units 

multiplier 



RECORD of 
string 
string 
real 



Function = RECORD of FN name : string 

Unit Type = RECORD of UTP TEXT : string 



Target Type = RECORD of TTP TEXT : string 

Emitter Suite = RECORD of ES name : string 

Word Indicator = RECORD of Word Integer : integer 

Sensor Package = RECORD of SP name : string 

SP number : integer 

CRRGet Routine = RECORD of Create Routine : integer 

Associated Directive = REQORD of AD dir ID : string 



Month = RECORD of 

Mth name : string 

Mth length : integer 



Order Record = RECORD of 

OR time text : string 

OR time : real 

OR DP meaning : integer 

OR status : string 

OR Message : string 

Associated Directive : RECORD 



Player Order * = RECORD of 
PO class 

PO specific type 
PO unit 

PO time effective 
PO word 1 integer 
PO word 2 integer 
PO word 3 integer 
PO word 4 integer 
PO word 5 integer 
PO array 1 pointer 
PO array 2 pointer 
PO array 3 pointer 
PO array 4 pointer 
PO array 5 pointer 
PO word 1 real 
PO word 2 real 
PO word 3 real 
PO word <► real 
PO word 5 real 
PO word 1 text 
PO word 2 text 



integer 

integer 

integer 

real 

integer 

integer 

integer 

integer 

integer 

integer 

integer 

integer 

integer 

integer 

double extended 
double extended 
double extended 
double extended 
double extended 
char 
char 
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Target = RECORD of 

TR pointer 
TR number 
TR name 
TR type 

VARIABLES 

Date Stamp, 

Status Line, 

Special Status, 

Player Line, 

User ID, 

Simulation Time Text, 

Scena r io Name , 

Game Classification, 

Supply Field : char* 

AMP Flag, 

■Starting Day, 

Starting Month, 

Starting Year, 

No of Login Builds, 

Air Refuel Index, 

Supply Width, 

Supply Precision, 

Sun Status, 

Number X Hexes, 

Number Y Hexes 

Simulation Time, 

Supply Minimum, 

Supply Maximum, 

Lat Hex One, 

Long Hex One ♦ 

Lat East 
Lat West 
Long North 
Long South 

************************** Utility Functions and Procedures ************************** 

*These subroutines may or may not be representative of original MIP logic. If there is a 
correlation, then the MIP subroutine ID will be annotated within brackets to guide the 
programmer to that original source code.* 

Directive Display* 

*This display is called from a resource file, develops a specific directive's display, and 
draws it into the main window.* 



: integer* 



: real* 



integer 

string 

string 

integer 



Given a DP meaning* 

Read the resource file for the generic directive display* 

For each static item do* 

index I from 1 to 12* 

Get attribute prototype of DP meaning* 

index J from 1 to N* *N is the number of attributes 

for the given DP meaning. 



For I = J do* 

Change the static text to represent AP prompt and AP 
For each I > N do* 

Hide the static item so it can't be seen or enabled* 
Now draw the display into the main window* 



field code* 



End Directive Display* 



Attribute Display* 
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*This is activated when a directive attribute is highlighted. It determines what type of 
attribute it is, gets the appropriate type of control, gets a range/choice of eligible 
values , and assigns each of them a control. It then draws the control into a dialog box 
onto the screen. When a particular control is activated, that value is assigned to the 
attribute variable.* 

Given AP(J) with a DP Meaning* 

Read a resource file for the dialog box* 

For AP create routine (J) do CRRGet* [1100] 

Case of (1 to 25)* *get the appropriate create control routine 
Draw the dialog box with the eligible values and their controls* 

For activated dialog box assign a value to word* 

*0f Word Integer of AP(J). 

End Attribute Display* 



Assignment * 

*This procedure handles the anomalies found when assigning directive-specific attributes 
to the Player Order fields. All AIR directives (DP meaning 301 to 399) use assignment 300 
as well as their own specific assignments.* 

Given a DP meaning* 

Invoke assignment. DP meaning* [A101 to A10<+, A106, A123, A200 to A227, A300, A306, 

A312 to A314, A401 to A<+07, A501 to A503, A800 1 



End Assignment* 



Verify * 

*This procedure verifies that certain directive-specific assignments were made before 
allowing the Player Order to be sent to tho CEP. The first part of the assignment checks 
for the existence of a referenced utility directive and the remainder invokes the 
d i rect ive-spec ific verif ica t ions . * 

The send flag is not set* 

Given a DP meaning* 

For each utility directive in directive* 

Determine it exists: 

No : Draw an error dialog box to alert the player* 

Yes : Then go on* 

If utility directive is weapon load* 

Determine weight of load for Aircraft is OK: 

No : Draw an error dialog box to alert the player* 

Yes : Then go on* 

Invoke verify. DP meaning* [V101, V104, V106, V123, V200 , V202 to V209, V211, V214, 

V217, V218, V222 , V225, V300 , V306, V312, V<+01 to V<+07, 
V501, V800 1 

End Verify* 



Retrieve Directive Attributes* (U0191 

*This procedure assigns a blank string to attributes with "Null Entry" as values. This 
permits acceptable formatting of the Player Order.* 

Given word integer* 

Case of that word* 

End Retrieve Directive Attributes* 



Player Order Assignment* [A0001 
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*This procedure assigns directive common attributes to specified Player Order fields. 
Given a DP meaning it then invokes that directives specified assignment.* 

Given Directive with DP meaning* 

PO class = DP CEP class* 

PO specific type = DP meaning* 

PO time effective = DIR time* 

PO word 2 text = DIR ID* 

If DIR unit 1 name * Null Entry* 

For UT short name = DIR unit 1 name* 

Let PO unit = UT pointer* 

Invoke Assignment . DP meaning* 

End Player Order Assignment* 



Mail the Player Order/Message* [U0181 

*This procedure concatenates the Player Order into one string of char for purposes of 
sending it to the CEP. After the Player Order is made, it is read to port. This is done 
by invoking Write To VAX. Then the Player Order is reset to 0.* 

Given a Player Order* 

For directive with DP meaning = 101* 

Increment No of Login Builds* 

Convert all integer and real values to character* 

Concatenate all Player Order fields into one string* *This is known as a message. 
Determine that the message will fit into the mailbpx: 

No : draw an error dialog box to alert the player* 

Yes : If message is directive then* 

OR time text = Simulation time text* 

OR DP meaning = DP meaning* 

OR unit = DIR unit 1 name* 

AD DIR ID 1 = DIR ID* 

File Order Record* 

If mode is "on-line" put the Player Order message into the mailbox* 

Reset Player Order = 0* *For the next time. 

End Mail the Player Order/Message* 



Quick Order Display* 

*This procedure is similar to Directive Display but on a smaller scale.* 
Given a QOP context* 

Read the resource file for the generic display* 

For each static text item do* 

Index I = 1 to 6* 

Get Quick Attribute Prototype for QOP context* 

Index J = 1 to N* *N is the number of attributes. 

For I = J do* 

Change the static text to represent QAP prompt* 

For I > N do* 

Hide the static text so it can't be seen or enabled* 
Now draw the display into the main window* 

End Quick Order Display* 



Quick Attribute Display* 

*This is similar to Attribute Display but on a smaller scale.* 

Given QAP(J) with QOP context* 

Read the resource file for the dialog box* 

For QAP Create Routine ( J ) do CRRGet: 

Case of (1 to 25 ) : Do Create Control* *As appropriate. 
Draw dialog box with eligible values and controls* 
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End Quick Attribute Prototype* 



List Control* 

*This procedure develops and draw a dialog box with controls for each item in the list. 
It returns a value of char.* 

Given N number of items in list* 

If List is multiple entry then 

Assign a check box for each item* 

Else 

Assign a radio button for each item* 

Map item to graphics position* 

Draw the dialog box in the main window* 

End List Control* 



Time Dial Control* 

*This procedure develops and draws a dialog box with a scroll dial to return a value of 
time. Minimum time always = 1 minute.* 

Given maximum day value* 

Given game minimum time* *If time is for "Duration" then game minimum time = 0 

since the value needed is a block of time for incre- 
mental purposes. 

Determine minimum and maximum values for the control: 

Minimum value = game minimum time + 1* 

Maximum value = game maximum time + maximum days* 

Draw a scroll dial using minimum/maximum values* 

Current value is minimum value* 

Format is 2 places for days* 2 places for hours, 2 places for minutes* 

Return a time value* *Usually is converted to a real number in terms of days. 

End Time Dial Control* 



Lat/Long Dial Control* 

*This procedure develops and draw a dial control onto the dialog box to return geographic 
points. Only degree fields must have values. Direction value in text converts i for 
real values of lat/long.* 

Given a minimum and maximum value* *Usually the game boundaries. 

Determine the number N of points to be made* 

Draw a scroll dial with minimum/maximum values* 

Current value is minimum value* 

Format is 3 places degrees, 2 places minutes, 2 places seconds, and 1 place 
direction* *For lat the first place has a value of 0. 

For N points do* 

Enter a latitude* 

Enter a longitude* 

Convert all points to real values* 

End Lat/Long Dial Control* 



Integer Dial Control* 

*This procedure develops and draws a dial control in a dialog box and returns an integer 
value.* 

Given a minimum and a maximum value* 

Draw a scroll dial with minimum/maximum values* 

Current value is minimum value* 

Format is 5 places* 

Return an integer value* 



77 



End Integer Dial Control* 

Real Dial Control* 

*This develops and draws a dial control with minimum and maximum values and returns a real 
value.* 

Given minimum and maximum values* 

Current value = minimum value* 

Format is 9 places with 5 decimal places* 

Draw a scroll dial with minimum and maximum values* 

Return a real value* 

End Real Dial Control* 



Lat/Long Conversion * [UQ13 , U014, U015, UQ16] 

*This develops the game surface boundaries in terms of latitude/longitude for use as dial 
ranges.* 

Given Lat Hex One, Lon Hex One, Number Y Hexes , and Number X Hexes* 

Convert to Lat Hex X, Lon Hex Y* 

Convert hexes to coordinates* , 

Results in Latitude East/West and Longitude North/South* 

End Lat/Lon Conversion* 



Read From VAX* 

*This uses the RS-232 port as a device and reads an ASCII file from the device if 
something is in the buffer. The buffer must be checked periodically.* 

End Read From VAX* 



Write To VAX* 

*This writes an ASCII file to the RS-232 port when called to do so by the Macintosh. It 
contains protocol information for the VAX and Macintosh to communicate.* 

End Write To VAX* 



PIF Update* [CEP Process] 

*This reads a message from the CEP, determines it's type and subtype , and take the 
necessary actions depending upon the type.* 

Read From VAX* 

For message type case of : 

< 1 ) Message : do 

increment queue by 1* 
file message in queue* 

Write The Status given queue* 

(2) Time : do Write The Status given time* 

(5) Interrupt pending : do Write The Status given special status* 

(6) Target : do a new target record* 

(7) Game speed : do Write The Status given game speed* 

(8) Stop password : change the password* 

(9) PIF updates : case of subtype : 

(1) Aircraft available : find the unit, change it's number* 

(2) Cargo trucks available : find the unit, change it's number* 

(3) Tanker trucks available : Find the unit, change it's number* 

(4) Aircraft characteristics : change the aircraft's record* 

[U028 ] 

Air weapon characteristics : change the air weapon’s record* 
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( 5 ) 



[ U029 ] 

(6) Personnel weight : change the personnel logistics load record* 

(7) Aircraft name : change the aircraft's name* 

(8) Air weapon name : change the air weapon's name* 

(9) Sensor package name : change the sensor package's name* 

(10) Emitter package name : change the emitter package's name* 

(11) Supply category : change a supply category's record* 

(10) Sunrise-sunset : do Write The Status given sunstatus* 

End PIF Update* 



Write The Status 

*This procedure develops and draws the status window and the information it contains.* 

Given queue , game speed , starting time and date, and special status* 

Read a resource file to get a dialog window* 

For each static text, change the static text to the necessary value* 

Draw the dialog box* 

End Write The Status* 



Write The Player* 

*This procedure develops and draw the player window and the information it contains.* 

Given classification, player function, scenario name* 

Read a resource file to get a dialog window* 

For each static text, change the static text to the necessary value* 

Draw the dialog box* 

End Write The Player* 



CRRGet Procedures* 

*These procedures get certain information for attributes and directives. Each gets some 

specific information, thus they are listed along with their MIP module number.* 

Get an ID CU101] 

Get a Duration [U110] 

Get a Lat and Long [Ullll 
Get a New Target Name [U106] 

Get a New Target Number [U105] 

Get a Real Number CU114] 

Get a Route CU115] 

Get Additional Route Info CU026] 

Get a Runway Name [U124] 

Get a Sensor List (U1181 

Get a Supply Changes List [U1221 

Get a Supply Load [U116] 

Get a Target Name [U104] 

Get a Target Types List [U123] 

Get a Targets List CU113] 

Get a Time [U1091 
Get a Unit Name [U103I 
Get a Units List CU112I 
Get a Weapon Load CU117I 
Get an Emitter List [U119I 
Get an Integer CU112] 

End CRRGet* 



*********************** Menu Driven Functions and Procedures *********************** 
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*** Apple Menu Functions and Procedures *** 

Do About v 

*This procedure simply tells the user some information about MacMIP.* 

Read the information needed from resource files* 

Put together a string of parameter text* 

Get the dialog box and put it up* 

When it has been read> get rid of it* 

End Do About* 



Do Desk Accessory* 

*This gets the selected desk accessory and starts it up.* 

Save a port for the desk accessory* 

Get the desk accessory name* 

Start the desk accessory* 

End Do Desk Accessory* 



*** File Menu Functions and Procedures *** 
Create* CCommand(l) of C000 ] 



*This procedure determines what directive to build and does it.* 



Determine the directive type (Action or Utility)* [C0011 

For type selected put up a dialog window with list of DP meanings* 

Given list do List Control* 

Return the selected value = DP meaning* 

Dispose of that window* 

Given DP Meaning do Display procedure* [C0021 

For each attribute highlighted do Attribute Display procedure* *Get a value 

for the 



attribute. 



Do Retrieve Directive Attributes procedure* 



End Create* 



Send* t Command! 101 ) of COOO ] 

*Sends only action directives > not previously sent* to CEP. The file sent must be open in 
window. * 

Given DP meaning do Verify procedure* 

Check verify flag case of: 

Not set : verify and set flag* 

Set : go on* 

Do Player Order Assignment* 

Mail the Player Order/Message * 

End Send* 



Do Verify* [Command! 106 ) of COOO] 

Check verify flag case of : 

Set : Tell player that directive is OK* 

Not set : For DP meaning do Verify procedure* 

End Verify* 



so 



*** Group File Menu Functions and Procedures *** 

Group Create* [Command! 51) of C000 1 

*This procedure creates a group of directives.* 

Get a unique ID for the group* 

List the action directives which do not already belong to a group* [C103] 
Do List Control* 

Return a value* 

Place the selected directive in the group* 

End Group Create* 



Join* [Command! 109 ) of C000 ] 

*This procedure adds a directive to a group.* 

Given an open directive put it into an existing group* [C103] 
End Join* 



Leave* [Command! 110 ) of C000] 

*This procedure removes a directive from a group.* 

Given an open group and a list of it's directives* CC104] 

Do List Control 

Returned value is selected directive* 

Remove selected directive from group* *It will stand alone. 

End Leave* 



Group Send* [Command! 54) of C000 ] 

*This procedure sends a group to the CEP by sending a directive at a time.* 

Check group to ensure Directives with DP meanings 310 and 800 aren't in the group at 
the same time* [C009] 

Yes : remove one of them* 

No : then for each DP meaning do Verify* 

Nhen all are verified do for each : Send* *0ne at a time. 

End Group Send* 



Group Verify* [Command! 58) of C000 ] 

*This procedure verifies a group of directives.* 

Do Verify procedure for each directive in group* [C009] 

Except if DP meaning = 800* Verification not done on Air Mission Package. 
Set verified flag* 

End Group Verify* 



Group Time Increment* [Command! 59) of C000 1 

*This procedure creates a block of time to add to a group.* 

Check group directives for DIR Time Text 5* 0 and DIR Time Text * Null Entry* 
IC010] 

If so for that directive! s) increment DIR Time and DIR Time Text* 

Do Time Dial Control* 

Return a block of time* 
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End Group Time Increment* 



*** Special Menu Functions and Procedures *** 



Transmit Message* (Command! 5) of C000 ] 

*This procedure allows the player to create a text message to send to another player.* 

Select Player! s) to send message to* (COlOl 
Includes "all", “all Blue", "all Red"* 

From is entered as' Player's function and side* 

Enter message as a text string* 

Enter "//" To indicate the end of the message* 

Invoke Player Order Assignment* 

Invoke Mail the Player Order/Message* 

Do as a repeating loop to place into each mailbox as required* 

End Transmit Message* 



Receive a Message* (Command! 14) of C000 ] 

*This procedure is invoked only when their is a CEP message in the queue. It pulls out 
the CEP message on a FIFO basis for the player to read or print.* 

Read message file for first message* [C006] 

Draw that message to the main window* 

End Receive a Message* 



Query* [Command! 13) of C000 ] 

*This procedure creates request for the CEP to send a progress report to the player. It 
is similar to creating a quick order.* 

For QOP context = 90 invoke Quick Order Display* (C017) 

Do List Control to return the type of report* 

Given a report type do Quick Attribute Display* 

Do Player Order Assignment* 

Do Mail the Player Order/Message* 

End Query* 



Graphics Adjust* 

*This procedure makes adjustments to the player's graphics station.* 

For QOP context = 98 invoke Quick Order Display* [C017] 

Do List Control returning the type of adjustment* 

Given an adjustment type invoke Quick Attribute Display* 

Do player Order Assignment* 

Do Mail the Player Order/Message * 

End Graphics Adjust* 



*** Find Menu Functions and Procedures *** 



Find Group* 

*This procedure invokes the operating system finder given the type of "group".* 
End Find Group* 
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Find Directive* 



*This procedure invokes the operating system finder given the type of "type of 
directive" .* 

End Find Directive* 



Find Utility* 

*This procedure invokes the operating system finder given the type of "type of utility 
directive" .* 

End Find Utility* 

Find Message* 

*This procedure invokes the operating system finder given a type "filed messages".* 

End Find Message* 

Find Report* 

*This procedure invokes the operating system finder given a type "filed reports".* 

End Find Report* 



************************ Event Driven Functions and Procedures ************************ 



Mouse Click* 

*Th,is identifies where the mouse was clicked and invokes the necessary procedure.* 

For location case of : ^Somewhere in the main window. 

Menu bar : Do Handle Menu* 

Content : Do Handle Click *In the main window to handle the attributes. 

Close box : Do Handle Close 

System window : Do System Click *This is a click in a desk accessory. 

End Mouse Click* 



Keypress* 

*This handles the event of any keystroke including the use of command keys.* 
End Keypress* 



Update* 

*This invokes the necessary update procedure depending upon the event.* 
Case of : 

Status window : Do Write The Status* 

Player window : Do Write The Player* 

Main window : 

Get the new information to go into the contents* 
Erase the current contents* 

Draw the new contents in it's place* 



End Update* 



Handle Event* 
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*This determines what event occurred and handles it.* 



Case of : 



Mouse Click 


Do 


Mouse Clicks 


Key down 


Do 


Keypress s 


Autokey 


Do 


Keypress s 


Update event 


Do 


Updates 


Activate event 


Do 


Activate s 



End Handle Events 



Cursor Adjusts 

*This changes cursors based upon the location of the cursor on the screen. These are 
application specific changes, not those made by the operating system. These may not be 
need for MacMIP but is included here just in case.* 

Do change to cross, arrow, plus) 

End Cursor Adjusts - 



Handle Menus 



*This procedure handles the event of any menu item being hit and invokes the necessary 
action to take place.* 



Case Menu of : 

Apple Meru : Case of 

About 

Desk Accessory 
File Menu : Case of : 

Create ‘ : 
Open : 

Save : 

Save As . . . 

Close : 

Print 

Send : 

Verify : 

Quit : 

Group Menu : Case of 

Create 
Leave 
Join 
Send 
Verify 

Time Increment 
Special Menu : Case of 

Transmit Message 
Receive Message 
Query 
Graphics 

Find Menu : Case of 

Group : 

Directive : 

Utility : 

Message : 

Report : 

Edit Menu : Case of 

Undo 
Cut 
Copy 
Paste 
Clear 

Select All 
Clear 



: Do About s 

: Do Desk Accessory s 

Do Creates 

operating system features 
operating system features 
operating system features 
operating system features 
operating system features 
Do Sends 
Do Verifys 

operating system features 

Do Group Creates 
Do Leave s 
Do Joins 
Do Group Sends 
Do Group Verifys 
Do Increment Group Times 

Do Transmit Messages 
Do Receive Messages 
Do Query s 

Do Graphics Adjusts 

Do Find Groups 
Do Find Directives 
Do Find Utilitys 
Do Find Messages 
Do Find Reports 

operating system features 
operating system features 
operating system features 
operating system features 
operating system features 
operating system features 
operating system features 
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End Handle Menu* 



**** **************** Initialization Functions and Procedures ******************** 



Initialization* 

*This procedure initializes the various Macintosh managers > variables, and procedures. It 
also initializes the PIF by reading in the appropriate database information.* 

Initialize* 

Graf Port, Font, Window, Menu, Text, Dialog, Events Managers. 

Cursors * 

Menus * 

Windows * 

Variables * 

Supply Field = "nnnnnnnnn.nn" * 

Supply Min = 0.0* 

Supply Max = 999999999.99999* 

Supply Width = 15* 

Supply Precision = 5* 

Month (1 to 12) = Jan.. Dec* 

Month Length (1 to 12 ) = 31.. 31* 

Load database information* CI000] 

Write to VAX* 

"Open C.datalmiscel.dat" 

"Read C.data3miscel.dat" 

Read From VAX* 

Store data into appropriate files* 

, Write To VAX* 

"Close C.datalmiscel.dat"* 

"Open C.data3executive.dat"* ClOOll 
"Read C.datalexecutive.dat"* 

Read From VAX* 

Write To VAX* 

"Close [.datalexecutive.dat"* 

"Open C .data 3drctvs<funct ion number>. dat" * C 10031 
"Read C . data ldrctvs<f unction number> .dat" * 

Read From Vax* 

Write To VAX* 

"Close [ .data ldrctvs<funct ion number>. dat" * 

"Open [.datalalldrctvs.dat"* C 10031 
"Read C.datalalldrctvs.dat'* * 

Read From VAX* 

Write To VAX* 

"Close [ .data lalldrctvs . dat ; 

"Open C .data lquicK< function number >. dat" * 

"Read l . data lquicK<function number< . dat" * C 10031 
Read From VAX* 

Write To VAX* 

"Close [ .data lquick<function number>.dat* 

For MIP mode = "on-line"* 

Write To Vax* 

Call VAX ' SYS$CREMBX' * *Create the mailboxes . C 1302 1 
Read From VAX* *Get the mailbox names. 

Load the PIF* C 10031 
Write To VAX* 

Given function number and type of game = "start"* 

"Open P F_Un i t ( f ile_type )" * 

Read From VAX* 

Read game class, starting day, starting month, starting year* 
Latitude/Longitude information* 

Unit names, types, and resource information* 

Target names, types, numbers* 

Supply side/category names, units, multipliers* 

Aircraft information* 

Air weapon information* 
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Sensor package informat ion * 
Emitter suite information* 
Write To VAX: 

Close PF_unit( f ile_type ) * 



End Initialization* 



*************************************** CLEANUP ********************************* 



Cleanup* 

*This procedure simply erases the screen when the game is finished* logs off the VAX* and 
shuts down the Macintosh.* 

End Cleanup* 

**************************************** MAIN *********************************** 



BEGIN MacMIP * 

Call Initialization* 

Repeat until finished* 

System Task* *For desk accessories. 

Cursor Adjust* 

If GetNextEventC everyE vent >theE vent 1 * *If there is an event... 
Then Handle Event( theEvent ) * *...then do it. 

Call Cleanup* *Hhen finished. 

*END MacMIP. 
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